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Preface 


This  report  is  the  result  of  a study  to  identify  a technical 
approach  for  the  design,  development  and  certification  of  a prototype 
secure  general-purpose  computer  system.  The  documented  approach 
including  the  example  schedules  and  resource  estimates  does  not  repre 
sent  an  approved  Air  Force  program  but  merely  describes  one  feasible 
structuring  of  the  project  with  associated  estimates  of  the  magnitude 
of  effort  required. 
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Introduction 


Introduction  To  The  Integration  Plan 


The  problem  of  security  in  computer  systems  has  been  under  study 
for  several  years.  The  Air  Force  has  sponsored  studies  and 
development  projects  aimed  at  improving  understanding  of  security 
in  computer  systems,  developing  a sound  theoretical  basis  for 
further  work,  and  demonstrating  accomplishments  in  the  field. 
Many  of  these  projects  have  been  associated  with  the  Multics 
sys  tern . 
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certification  of  the  Multics  and  SFEP 


Backg  round 

The  military  faces  an  increasing  need  for  operational  computer 
systems  capable  of  processing  several  levels  of  classified 
information  at  the  same  time.  Present  systems  (except  Multics) 
are  unable  to  support  secure  multilevel  processing  due  to 
fundamental  weaknesses  in  their  basic  design  since  security  was 
not  a concern  when  they  were  developed.  The  weakness  is  that 
current  hardware/software  systems  are  unable  to  adequately 
protect  the  information  that  they  process. 


With  the  exception  of  the  two-level  Multics  system  developed  for, 
and  in  use  at,  the  Air  Force  Data  Services  Center,  the  military 
currently  meets  the  need  for  processing  several  levels  of 
information  by  one  of  two  methods.  Either  all  security  levels 
are  processed  together  at  the  level  of  the  highest  classification 
present,  or  each  level  is  processed  by  itself . Both  methods  have 
been  less  than  satisfactory.  The  problem  with  processing  all 
levels  together  is  that  all  users  and  all  equipment,  including 
terminals  and  communications  facilities,  must  be  cleared  to  the 
highest  classification  that  the  system  can  ever  process.  The 
problem  with  separate  processing  is  that  a separate  computer 
system  or  a separate  period  of  time  is  required  for  each  level 
handled.  Either  method  is  costly  and  inefficient.  Neither 
method  allows  simultaneous  handling  of  information  at  several 
levels  for  users  of  several  levels  of  clearance. 
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Multics  is  the  most  advanced  general  computing  system  as  far  as 
security  is  concerned.  Security  was  one  of  the  initial  design 
goals  of  the  Multics  system  designers  and  has  been  a major 
concern  of  the  designers  and  developers  throughout  the  history  of 
the  system.  - Even  with  this  concern  for  security,  the  present 
Multics  system  cannot  be  certified  secure.  Multics,  however, 
does  present  the  best  available  base  upon  which  to  build  a 
certifiably  secure  multilevel  computer  utility. 

Secure  communications  has  also  presented  operational  problems  to 
the  military.  A secure  on-line  system  requires  a secure 
communications  network.  While  the  techniques  of  securing 
communications  lines  and  terminals  have  been  well  developed,  a 
certifiably  secure  communications  processor  is  still  undeveloped. 
A secure  multilevel  system  must  have  a compatible  and  secure 
front-end  communications  processor  to  be  able  to  properly  handle 
multiple  levels  of  classified  information. 

Both  economic  and  operational  considerations  make  development  of 
a certifiably  secure  multilevel  system  desirable.  Recent 
advances  in  computer  technology  indicate  that  it  should  be 
possible  to  produce  a system  that  can  process  an  arbitrary  mix  of 
classified  and  unclassified  information  simultaneously  on  a 
single  computer  system.  The  system  should  serve  both  cleared  and 
uncleared  users  and  shoulo  rely  on  the  computer  system's  internal 
hardware/software  controls  to  enforce  security  and  need-to-know 
requirements.  Of  primary  importance  is  that  the  system  be 
certifiably  secure.  That  is,  it  must  be  possible  to  prove  that 
the  system  is  complete  and  without  flaw  in  any  of  its 
security-related  aspects. 

The  Air  Force  has  been  working  on  the  problem  of  providing  a 
certifiably  secure  multilevel  system.  In  1970,  the  Air  Force 
Data  Services  Center  (AFDSC)  requested  the  Electronic  Systems 
Division  (ESD)  to  support  development  of  an  open  multilevel 
system  for  the  AFDSC  Honeywell  635  systems.  The  resulting 
studies  pointed  out  the  severity  of  the  problem  and  led  to  the 
formation  of  a computer  security  technology  planning  study  panel. 
The  panel's  report  (1)  described  the  fundamental  problems  and 
delineated  a program  to  develop  the  desired  system.  The  panel 
recommended  that  the  technical  approach  to  the  problem  be  "to 
start  with  a statement  of  an  ideal  system,  a model,  and  to  refine 
and  move  the  statement  through  various  levels  of  design  into  the 
mechanism  that  implements  the  model  system". 

The  basic  component  of  the  ideal  system  was  also  identified  by 
this  panel.  This  component  is  known  as  the  Reference  Monitor,  an 
abstract  mechanism  that  controls  access  of  subjects  (active 
system  elements)  to  objects  (units  of  information)  within  the 
computer  system  and  enforces  the  rules  of  the  military  security 
system  on  such  access.  Three  requirements  were  recognized  for  a 
Reference  Monitor : 
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1.  Complete  Mediation  - the  mechanism  must  mediate  every 
access  of  a subject  to  an  object. 

2.  Isolation  - the  mechanism  and  its  data  bases  must  be 
protected  from  unauthorized  alteration. 

3.  Verifiability  - the  mechanism  must  be  small,  simple, 
and  understandable  so  that  it  can  be  completely  tested 
and  verified  (certified)  to  perform  its  functions 
correctly . 

The  mechanism  that  implements  the  Reference  Monitor  in  a 
particular  computer  system  has  been  termed  the  security  kernel. 
Much  subsequent  work  has  been  devoted  to  identifying  the 
characteristics  of  a security  kernel  and  to  exploring  the 
technology  involved  in  producing  a security  kernel  for  some 
computer  system. 

BSD  initiated  development  of  formal  mathematical  models  of  the 
ideal  Reference  Monitor  in  1972.  This  work  (2,3)  resulted  in  a 
model  of  a secure  computer  system  as  a finite-state  mechanism 
that  makes  explicit  transitions  from  one  secure  state  to  another. 
The  rules  of  the  model  formally  define  the  conditions  under  which 
a transition  from  state  to  state  can  occur.  The  rules  have  been 
proven  to  allow  only  transitions  that  preserve  the  security  of 
information  in  the  system.  The  model  specifies  requirements  for 
the  operation  of  a security  kernel.  These  requirements  were  taken 
directly  from  the  Defense  Department  regulations  on  handling 
sensitive  information  (DoD  Directive  5200.1-R).  With  the 

availability  of  the  model,  the  problem  of  validation  is  now 
reduced  to  providing  complete  assurance  that  a particular 

security  kernel  behaves  exactly  as  the  model  requires. 

Work  on  the  technology  of  certification  progressed  in  parallel 
with  the  work  on  the  model.  In  1973,  W.  Price  (4)  identified  a 
methodology  for  verification  of  a kernel.  More  detailed 
developments  of  this  validation  methodology  have  been  reported  by 
MITRE  (5,6).  Another  approach  has  been  explored  which  may  be 
more  suitable  to  large  software  modules  (7). 

Other  activities  have  been  devoted  to  the  problem  of  building  a 
security  kernel  for  a practical  system  (8,9) . This  work  has 
demonstrated  the  soundness  of  the  basic  concepts  and  also  pointed 
out  some  of  the  problems  that  lie  in  the  way  of  realizing  a 
security  kernel  on  a large  system.  This  work  has  been  the  basis 
for  development  of  a secure  communications  processor,  a detailed 
effort  which  is  presented  later  in  this  report. 

A major  project  in  the  development  process  is  the  development  of 
a security  kernel  for  a large  resource  sharing  system.  The 
system  chosen  for  this  effort  is  Multics.  There  are  two  reasons 
that  this  choice  was  made.  First,  the  hardware  base  of  the 
Multics  system,  the  Honeywell  68/80  computer,  has  been  identified 
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as  best  suited  of  all  off-the-shelf  large  computer  systems  for 
the  support  of  a security  kernel  (10).  Second,  the  Multics 
system  architecture  was  conceived  and  developed  with  security 
requirements  specifically  in  mind. 

One  project,  now  completed,  involved  the  design  and  production  of 
a Multics  system  capable  of  supporting  a two-level  (Secret  and 
Top  Secret)  environment  for  the  Air  Force  Data  Services  Center 
(11,12).  This  system  implements  security  controls  based  on  the 
military  access  rules,  but  it  does  not  completely  handle  the 
threat  of  a hostile  penetration.  From  these  efforts,  additional 
insight  was  gained  in  the  problems  of  designing  and  developing  a 
security  kernel  for  Multics. 


Summary  of  Integration  Plan 

Design  of  a security  kernel  for  Multics  was  started  as  a joint 
effort  among  personnel  from  ESD,  the  MITRE  Corporation,  the 
Massachusetts  Institute  of  Technology,  and  Honeywell  Information 
Systems.  This  design  effort  has  led  to  a more  complete 
understanding  of  the  general  problem  and  has  provided  the 
foundation  for  the  development  plan  which  is  presented  in  the 
following  sections  of  this  report.  Work  is  progressing  on  formal 
specifications  for  the  Multics  security  kernel  (13)  and  on 
simplification  and  reorganization  of  the  Multics  operating 
system.  Based  on  these  efforts,  this  report  describes  a major 
project  to  refine  the  current  Multics  system  and  reimplement 
critical  portions  of  the  system  to  produce  a certifiable  kernel 
which  will  interface  with  a certifiable  front-end  communications 
processor  with  its  own  security  kernel.'  The  result  will  be  a 
prototype  Multics  system  which  may  meet  the  goal  of  Air  Force 
certification. 

The  project  can  be  described  in  terms  of  three  coordinated 
development  activities;  development  of  hardware  for  a prototype 
Secure  Front-End  Processor  (SFEP)  and  Interface  Units; 
development  of  a security  kernel  for  the  Secure  Front-End 
Processor;  and  development  of  a certifiable  prototype  secure 
Multics  including  the  Secure  Front-End  Processor. 

Programming  methodologies  and  techniques  will  be  selected  to 
support  the  major  Multics  and  SFEP  development  activities. 
Included  are:  techniques  for  formally  specifying  software; 
techniques  for  demonstrating  the  correspondence  among 
hierarchically  ordered  levels  of  specification;  programming 
languages  (or  subsets  of  programming  languages)  emphasizing  the 
generation  of  certifiable  code;  support  tools  aiding  the  task  of 
certifying  both  specifications  and  code;  and  techniques  for 
performance  measurements. 

The  Secure  Front-End  Processor  is  developed  using  a hardware 
architecture  designed  specifically  to  provide  a basis  for 
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certification  according  to  the  Air  Force  security  model.  The 
hardware  provides  segmented  addressing  and  interfaces  directly 
with  the  prototype  Multics  system.  The  software  provides  a 
kernel-based  system  architecture  with  a supervisor  supporting 
communications  subsystems  for  external  I/O.  The  initial  version 
of  the  SFEP  software  is  integrated  with  the  kernel-based  Multics 
system  to  demonstrate  functional  capability.  A second  SFEP 
version  is  then  coded  in  the  selected  system  programming 
language,  incorporates  performance  enhancements  and  is  then 
integrated  with  Multics. 

Development  of  the  certifiable  prototype  Multics  system  entails 
the  restructuring  of  the  present  Multics  supervisor  to  rely  on  a 
formally  specified  security  kernel  leading  to  three  demonstration 
systems.  The  preliminary  Multics  demonstration  employs  a 
formally  specified  kernel,  coded  in  PL/I,  interfacing  with  a 
DATANET  6600  front-end  processor  and  establishes  functional  and 
performance  measures  of  the  design.  The  intermediate  Multics 
demonstration  incorporates  the  Secure  Front-End  Processor  to 
demonstrate  successful  integration  of  the  two  hardware  systems 
with  their  respective  kernels  and  supervisors.  The  operational 
prototype  Multics  demonstration  incorporates  performance 
enhancements  and  contains  Kernels  coded  in  the  selected  system 
programming  language.  This  last  system  establishes  the 
feasibility  of  certifying  code  correctness  aided  by  the  support 
tools  developed  as  part  of  the  project. 

The  kernels  for  the  operational  prototype  Multics  demonstration 
will  be  developed  in  a secure  development  facility.  Upon 
successful  conclusion  and  demonstration  of  the  operational 
prototype  secure  Multics,  the  final  product  of  this  project  is 
then  available  for  installation  for  test  and  evaluation  purposes 
at  an  operational  government  service  site  such  as  the  Air  Force 
Data  Services  Center  (AFDSC) . The  actual  installation  and 
evaluation  of  tne  operational  prototype  secure  Multics  is  beyond 
the  scope  of  tnis  five  year  plan.  However,  a conversion  plan  and 
approacn-  to  describe,  achieve,  and  support  that  installation  is 
provided  in  this  Integration  Plan. 

This  Integration  Plan  encompasses  a five  year  effort  during  which 
major  technical  milestones  will  occur.  The  attached  schedule  of 
milestones  shows  the  planned  time  frame  for  these  major  technical 
events  which  are  described  as  follows: 

1.  SFEP  Development  Unit 

Delivery  of  SFEP  system  hardware  to  the  hardware  system  test 

software  development  facility  at  Honeywell's  Aerospace 

Division . 
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2.  Preliminary  Multics  Demonstration 

Specification,  design,  implementation,  and  demonstration  of 
the  first  kernel-based  Multics  system.  This  system  is  coded 
in  PL/I  and  utilizes  a DATANET-6600  communications  processor. 

3.  SFEP  Prototype  System 

Specification,  design,  and  assembly  language  implementation 
of  a prototype  SFEP  software  system. 

4.  TEMPEST  Tested  SFEP  Hardware 

Availability  of  prototype  SFEP  hardware  which  conforms  to 
TEMPEST  requirements. 

5.  System  Programming  Language 

Availability  of  operational  compilers  which  facilitate 
program  correctness  proofs  to  support  the  reimplementation  of 
the  Multics  and  SFEP  kernels  for  the  operational  prototype 
Multics  demonstration. 

6.  Intermediate  Multics  Demonstration 


Demonstration  of  an  integrated,  PL/I-coded,  kernel-based 
Multics  system  with  SFEP  capabilities. 

7.  Tools  for  Correctness  Proofs 


Selection  of  correctness  proving  tools  to  facilitate 
certification  of  the  kernels  in  the  operational  Multics 
prototype . 

8.  Begin  Correctness  Proofs 


Begin  feasibility  demonstration  for  proof 
between  the  specification  and 

implementations. 


of  correspondence 
kernel  software 


9.  Operational  Prototype  Multics  Demonstration  (Recoding  and 
System  Integration) 


Reimplementation  of  the  security  kernels  in  the  selected 
system  programming  languages  and  implementation  of 
performance  enhancements. 

10.  Correspondence  Technology  and  Specification  Proofs 

Completion  of  the  correspondence  proofs  between  the  model 
and  the  kernel  specifications  for  the  prototype  using  the 
available  correspondence  proof  tools. 
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11.  Establish  Secure  Development  Site 

Availability  of  a secure  computer  facility  which  provides  a 
Top  Secret  controlled  environment  in  which  software 
development,  system  tests,  and  certification  can  be 
undertaken . 

12.  Operational  Test  and  Evaluation  Site 

Availability  of  an  operational  Multics  site  which  will 
provide  the  environment  for  the  Test  and  Evaluation  of  the 
secure  Multics  system  under  operational  service  conditions. 
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MASTER  MILESTONE  SCHEDULE 
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To  achieve  these  milestones,  the  plan  described  in  this  report 
has  been  broken  into  four  major  tasks.  These  tasks  are: 

Task  1 Multics  Development 

This  task  covers  all  activities  for  the  simplification  of 
the  present  Multics  system,  development  of  a security 
kernel  for  Multics,  development  of  the  supporting  tools 
and  techniques  required  to  produce  the  kernel,  support  of 
the  Secure  Front-End  Processor,  development  of  technology 
and  tools  for  certification,  and  beginning  of  the 
certification  Process  of  the  Multics  kernel. 

Task  2 Secure  Front-End  Processor  Hardware 

This  task  covers  all  activities  for  the  specification, 
design,  fabrication,  testing,  and  design  verification  of 
the  Secure  Front-End  Communications  Processor. 

Task  3 Secure  Front-End  Processor  Software 

This  task  covers  all  activities  required  for  the 
specification,  design,  programming,  development  of 
technology  and  tools  for  certification,  and  beginning  of 
the  certification  process  of  the  kernel  software  for  the 
Secure  Front-End  Communications  Processor. 

Task  4 Project  Support 

This  task  covers  the  activities  required  to  administer 
the  program,  to  support  the  task  developers  with 
documentation  services,  and  to  supply  the  computer 
services  required  for  the  completion  of  the  three 
technical  efforts  above. 

Each  major  task  is  the  subject  of  a section  of  this  report.  The 
format  of  each  section  is  an  introduction  to  tne  major  task 
followed  by  a definition  and  discussion  of  important  subtasks. 
Each  section  concludes  with  a schedule  which  shows  the  resource 
requirements  necessary  to  perform  each  task.  The  following 
schedules  show  the  major  subtasks  of  the  program. 
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PROJECT  GUARDIAN 

TASK  1.0  DEVEIjOPMENT  OF  A PROTOTYPE  MULTICS  KERNEL 
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PI^ECT  GUARDIAN 

TASK  1.0  deveu)phf:nt  of  a prototype  MULTICS  EERKEL 
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PROJECT  GUARDIMJ 

TASK  2.0  SECURE  FRONT  END  PROCESSOR  - HARDWARE 


PROJECT  GUARDIAN 

TASK  3.0  SECURE  FRONT  END  PROCESSOR  - SOFTWARE 
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A set  of  supporting  efforts  has  also  been  identified.  These 
additional  tasks  will  augment  the  system  or  improve  its  utility. 
These  efforts  are  desirable  additions  to  the  project,  but  are  not 
essential  to  meet  the  principle  goals.  Tne  currently  identified 
supporting  efforts  include: 

A.  Secure  Data  Base  Management  System 

This  effort  covers  the  design,  development,  implementation, 
and  test  or  certification  of  a Secure  Data  Base  Management 
System  to  operate  on  the  secure  Multics.  The  system  will 
allow  multilevel  access  to  a multilevel  data  base. 

B.  Cryptographic  Multiplexor 

This  effort  covers  integration  of  a multiplexed  cryptographic 
capability  with  the  Secure  Front-End  Processor. 

C.  Secure  Office  Terminal  Office  Terminal 

This  effort  includes  development  of  procedures  for  use  of 
crypto  communications  with  the  secure  Multics,  and  procedures 
for  use  of  a secure  office  terminal. 

D.  Security  Audit  and  Surveillance 

This  effort  covers  the  design  and  implementation  of 
facilities  for  security  audit  and  security  surveillance  of 
the  secure  Multics. 

The  supporting  efforts  are  described  in  Appendix  A of  this 
report.  The  format  of  the  sections  on  supporting  efforts  varies 
somewhat  from  that  of  the  sections  on  major  tasks,  due  to  the 
large  differences  in  the  nature  of  the  supporting  efforts.  There 
will  probably  be  additional  supporting  efforts  identified  and 
considered  during  the  progress  of  the  major  project. 
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Section  I 


Multics  Development 


Introduction  to  the  Development  of  a Prototype 
Kernel-Based  Multics  System 


This  part  of  the  Integration  Plan  is  concerned  with  modifications 
to  the  Multics  system  to  demonstrate  that  the  certifiable 
security  kernel  concept  is  feasible  for  a large-scale  computer 
utility.  Several  technical  reports  will  be  prepared  which 
together  will  describe  the  kernel-based  Multics  system. 

The  engineering  approach  for  this  effort  is  to  develop  three 
demonstration  kernel-based  Multics  systems  (evolving  from 
Honeywell's  standard  product  Multics  system),  each  with  increased 
function  and  correctness. 

The  first  demonstration  will  show  the  feasibility  of  the  kernel 
interfaces  for  Input/Output  (I/O)  and  support  of  the  nonkernel 
supervisor  functions.  Formal  specifications  for  the  kernel 
modules  will  be  developed  and  correspondence  proofs  between  these 
formal  specifications  and  the  security  kernel  model  will  be 
prepared.  In  developing  this  first  demonstration,  as  much  of  the 
existing  Multics  code  will  be  used  as  possible.  All  kernel 
development  will  be  done  in  the  PL/I  and  ALM  languages. 
Correctness  proofs  of  the  kernel  code  will  not  be  attempted.  The 
current  Multics  DATANET  6600  software  will  be  modified  to  support 
the  communications  interface  to  the  kernel. 


The  second  demonstration  system  will  integrate  the  Secure 
Front-End  Processor  (SFEP)  with  the  first  demonstration  system. 
The  formal  specifications  will  be  revised  as  needed  and  the 
correspondence  proofs  will  be  regenerated. 

The  third  demonstration  system  will  incorporate  the  performance 
enhancements  developed  from  the  results  of  the  first  and  second 
demonstration  system  performance  studies.  The  security  kernel 
will  be  recoded  in  the  new  system  programming  language  which  will 
be  developed  in  parallel  with  the  first  demonstration  system. 
Correctness  proofs  of  the  recoded  kernel  programs  will  be 
undertaken . 


Informal  technical  reports  describing 
effort  as  outlined  under  each  of  the 
will  be  available  to  • the  Air  Force 
project. 


the  demonstration  system 
following  task  descriptions 
over  the  course  of  tne 
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Task  1.1  System  Programming  Language  Development 

The  programming  language  to  be  used  in  coding  the  third  version 
of  the  prototype  security  kernel  must  be  easy  to  understand  if  a 
correspondence  between  the  formal  program  specifications  and  the 
executable  code  is  to  be  made.  The  current  system  programming 
language,  PL/I,  does  not  meet  this  requirement  as  it  exists 
today.  Therefore,  a programming  language  based  on  our  experience 
with  PL/I  will  be  developed.  This  language  will  be  a subset  of 
the  present  PL/I  language  with  some  necessary  modifications  or 
extensions  to  facilitate  certification.  The  language  is  also 
expected  to  be  used  during  the  SFEP  kernel  development  effort  of 
Ta  s k 3 . 5 . 

The  specification  for  a programming  language  to  be  used  in  the 
implementation  of  the  Multics  security  kernel  will  be  developed. 
The  major  goals  for  the  language  will  be: 

a.  easy  to  understand  syntactic  and  semantic  constructs 

b.  provide  extensive  support  for  manual  validation  techniques 

c.  fast  efficient  object  code 

d.  flexible  enough  to  support  system  programs 

e.  support  Multics  and  SFEP  kernel  development  efforts 

A system  programming  language  specification  manual  and  an 
operable  compiler  for  the  language  will  be  produced  by  this  task. 
This  specification  must  be  available  prior  to  the  start  of  Task 
1.24. 

Stanford  Research  Institute  (SRI)  will  act  as  a consultant  during 
the  language  development  on  issues  of  support  for  correctness 
proofs . 


Task  1.2  Establish  A Formal  Programming  Technology 

The  technology  for  formal  program  specification  is  relatively  new 
and  has  changed  greatly  during  the  last  few  years.  The  Multics 
environment  will  put  some  restrictions  on  the  choice  of  a formal 
language  which  can  be  used  effectively  in  the  correspondence 
proofs.  Therefore,  some  investigation  in  this  area  will  be 
necessary . 

The  technology  of  formal  program  specification  will  be  reviewed 
by  Honeywell  and  SRI.  A methodology  will  be  adopted  or  refined 
which  best  suits  the  Multics  and  SFEP  kernel-based  systems  and 
will  be  useful  in  the  formal  correspondence  proofs  for  the 
kernels.  The  techniques  for  generating  a formal  correspondence 
proof  between  a mathematical  model  and  a formal  program 
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specification  will  be  defined.  These  techniques  will  not  utilize 
fully  automated  tools;  instead,  semiautoraa ted  tools  to  assist  in 
manual  proofs  will  be  provided  to  aid  in  the  tracking  of  the 
software  throughout  the  life  of  the  project. 

A standards  document  will  be  written  which  describes  the 
application  of  the  formal  specification  method  to  Multics  and  the 
SFEP.  Emphasis  will  be  on  approved  practices  for  correct  kernel 
program  specification  to  support  the  correspondence  proofs. 

A detailed  programming  practices  document  will  be  developed  which 
will  build  on  the  standards  document.  This  work  will  be  expanded 
as  more  is  known  about  programming  practices  which  will  support 
correctness  proofs.  Particular  attention  will  be  paid  to  the 
application  of  the  modified  PL/I  system  programming  language 
(developed  under  Task  1.1)  to  proving  program  correctness. 


The  format  for  documentation  to  best  describe  the  structure  of 
program  modules  and  their  interdependencies  will  be  investigated. 
Techniques  will  be  developed  to  ensure  that  the  documentation 
will  track  changes  to  the  modules  properly.  These  techniques  and 
software  tools  which  implement  them  will  be  needed  for  the 
documentation  effort  described  in  Task  1.20.  A technical  manual 
describing  the  documentation  techniques  and  tools  will  be 
prepared  during  this  task. 


Task  1.3  Develop  Support  Tools  to  Coordinate  Multiple  Versions 
of  Multics 

After  tne  completion  of  the  first  demonstration  system,  there 
will  be  two  distinct  Multics  systems  supporting  (nearly)  the  same 
user  interface  (i.e.,  the  standard  product  Multics  and  the 
kernel-based  demonstration  system  Multics.)  These  two  systems 
must  track  all  changes  to  the  Multics  user  interface  as  closely 
as  possible.  Software  tools  to  aid  in  the  comparison  of  library 
programs  for  the  two  systems  are  needed.  Currently  available 
library  maintenance  software  tools  will  be  modified  and  extended 
to  support  the  second  collection  of  programs  dedicated  to  this 
development  effort.  These  maintenance  tools  will  identify  any 
differences  between  the  two  Multics  systems  on  a continuing 
basis  - 

This  task  will  involve  the  development  of  software  tools  (and 

possibly  manual  techniques)  to  support  the  maintenance  of 
parallel  Multics  systems.  As  a minimum,  complete  library 

comparison  programs  are  needed  to  identify  modules  which  have 
been  updated  in  one  system  and  not  in  the  other. 

A technical  manual  describing  the  support  tools  will  be  prepared 
during  this  task. 
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Task  1.4  Develop  Tools  to  Generate  and  Regenerate  Correspondence 
Proofs  and  Formal  Specifications 

During  the  course  of  the  project,  there  will  be  several  changes 
to  the  kernel  module  specifications  as  design  problems  are 
resolved.  For  each  change,  the  formal  specifications  and 
correspondence  proofs  may  have  to  be  updated. 

This  task  covers,  in  part,  the  SRI  effort  of  designing 
semiautoma ted  software  tools  for  generating  and  modifying  the 
formal  specifications  and  for  generating  and  regenerating 
correspondence  proofs.  These  tools  presently  exist  and  have  been 
demonstrated  for  other  applications  by  SRI.  They  must  be 
transferred  to  Multics  to  be  applicable  to  the  Multics  and  SFEP 
specification  efforts. 

Available  tools  developed  under  this  task  will  be  used  during  the 
development  of  the  second  demonstration  system.  They  will  also 
be  applied  during  the  design  of  performance  enhancements  for  the 
third  demonstration  system.  These  tools  will  also  be  applied  to 
the  correspondence  proving  task  for  the  SFEP  kernel  activity  in 
Task  3.4. 

Two  progress  reports  will  be  prepared  during  the  course  of  this 
task.  At  the  conclusion,  a technical  manual  describing  the  tools 
will  be  prepared. 


Task  1.5  Develop  Tools  and  Techniques  for  Kernel  Certification 
and  Recertification 

The  long-range  goal  of  this  project  is  to  show  that  the 
kernel-based  Multics  system  can  be  certified  as  secure.  To  this 
end,  a detailed  specification  of  the  criteria  for  certification 
must  be  developed.  This  specification  must  describe  the 
certification  process  from  the  formal  model  to  the  executable 
software  and  the  hardware.  The  certification  process  must  lend 
itself  to  an  orderly  recertification  as  the  kernel  evolves  and  as 
hardware  changes  are  incorporated. 

This  task  covers,  in  part,  the  SRI  effort  of  defining  the 
criteria  for  certification  of  the  kernel-based  Multics  and  SFEP 
systems  and  in  designing  tools  and  techniques  for  initial 
certification  and  recertification  as  the  system  changes.  Some 
research  into  the  handling  of  concurrency  and  exception 
conditions  will  be  required.  The  development  of  these  tools  will 
be  at  the  option  of  the  Air  Force. 
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Task  1.6  Ring  Zero  Simplification  Studies 

This  task  covers  the  MIT  Laboratory  for  Computer  Science 
(formerly  known  as  Project  MAC)  efforts  in  reducing  the  size  of 
ring  zero.  Many  of  the  areas  under  current  investigation  show 
promise  for  generating  design  approaches  which  would  be  useful  in 
the  kernel  development. 

I 

The  results  of  these  simplification  studies  will  be  reviewed  in 
detail  as  the  kernel  design  progresses.  The  ideas  described  will 
be  factored  into  the  kernel  design  as  appropriate. 

Each  area  of  study  will  be  described  in  technical  memos  as 
appropriate  during  the  course  of  this  task. 


Task  1.7  Develop  An  Informal  Prototype  Kernel  Description  and  A 
Top-Level  Formal  Prototype  Kernel  Specification 


This  task 
prototype 
that  will 
secur i ty 
tr ans itio 


involves 
kernel 
form  the 
of  the 
,s  will  be 


expanding  the  functional  description  of  the 
into  a more  detailed  specification  of  modules 
kernel,  including  their  interactions.  The 
initial  state  of  the  kernel  and  all  state 
shown . 


After  the  initial  work  of  this  task  has  been  completed,  a design 
review  with  the  Air  Force  will  be  held  to  ensure  that  the  Air 
Force  and  Honeywell  are  in  agreement  that  the  kernel  description 
will  support  the  security  model  as  well  as  the  requirements  of 
engineering  feasibility. 


The  kernel  description  will  now  be  the  basis  for  tne  development 
of  top-level  formal  prototype  kernel  specifications.  Each  of  the 
kernel  interfaces  will  be  described  using  the  formal  program 
specification  methodology  adopted  for  the  Multics  system  under 
Task  1.2. 

The  informal  kernel  description  and  the  top-level  formal  kernel 
specification  will  be  integrated  into  a detailed  prototype  kernel 
specification. 


Task  1.8  Develop  Top-Level  Correspondence  Proofs 

During  this  task,  Honeywell  and  SRI  will  work  together  to  prove 
that  the  top-level  formal  prototype  specification  corresponds  to 
the  Air  Force  security  model.  Progress  on  this  task  assumes  that 
the  informal  prototype  kernel  description  provided  to  the  Air 
Force  at  the  design  review  from  Task  1.7  has  been  accepted.  This 
task  will  also  serve  as  the  basis  for  the  similar  SFEP  Task  3.3 
which  is  described  later. 
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A technical  report  describing  the  top-level  correspondence  proofs 
will  be  prepared  at  the  conclusion  of  this  task. 


Task  1.9  Develop  Complete  Formal  Specifications  for  the  Multics 
Kernel  Modules 

This  task  will  extend  the  top-level  formal  prototype  kernel 
specification  to  the  lower  levels  to  include  the  various  modules 
within  the  security  kernel.  This  will  include  the  full 
specification  of  the  interfaces  between  all  modules  and  the 
functions  that  are  performed  by  each  module. 

An  update  to  the  detailed  prototype  kernel  specification  will  be 
prepared  at  the  conclusion  of  this  task. 


Task  1.10  Develop  Lower-Level  Correspondence  Proofs  of  the 
Multics  Kernel 

During  this  task,  Honeywell  and  SRI  will  work  together  to  prove 
that  the  complete  formal  specifications  of  the  prototype  kernel 
modules  follow  the  top-level  kernel  specifications  and  thereby 
follow  the  security  model  prepared  by  the  Air  Force.  A complete 
report  describing  the  correspondence  between  the  model  and  the 
top-level  kernel  specification  and  between  the  top-level  and 
lower-levels  will  be  prepared  at  the  completion  of  this  task. 


Task  1.11  I/O  Study  and  Design 

This  task  will  determine  how  external  I/O  should  be  handled  in 
the  kernel-based  Multics  system.  All  internal  I/O  will  be 
handled  by  the  kernel  through  an  I/O  Multiplexer  ( lOM) . All 
external  communications  will  be  handled  through  an  SFEP.  Between 
these  two  extremes  an  engineering  evaluation  will  be  made  to 
determine  how  other  forms  of  external  I/O  will  be  handled  within 
the  system.  Such  factors  as  physical  constraints,  data 
transmission  speeds,  system  initialization,  system  crash  recovery 
and  efficiency  must  be  considered  along  with  the  security  model 
to  determine  for  each  I/O  device  what  system  architecture  best 
satisfies  all  the  constraints. 

Early  in  the  course  of  this  task,  a design  review  will  be  held 
with  the  Air  Force  to  present  all  the  factors  on  handling 
external  I/O  within  the  kernel-based  Multics  system.  Complete 
agreement  between  Honeywell  and  the  Air  Force  on  the  design 
approach  is  necessary  before  work  can  continue  on  the  project. 

A technical  report  describing  the  recommended  approach  to 
handling  external  I/O  in  the  kernel-based  system  will  be  prepared 
during  this  task. 
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TasK  1.12  lOM/iirC  Firrr'.vvare/iiardwarc  l-icoif ications 

It  is  recognizee  tnat  the  I/C  stuay  may  recommend  certain 
moair ications  to  tne  ICM  in  the  rorm  of  hardware  changes  or  to 
tae  I'licroprogrammec  Controllers  (liFC)  either  in  the  form  of 
nareware  or  firmware  changes.  This  task  will  outline  such 
mooif ications  in  oetail  ana  oversee  their  correct  implementatioh. 

All  cnanges  to  haruware  anc/or  firmware  will  be  described  in  tne 
I/O  stuoy  report.  Hence,  no  aooitional  reports  will  be  generatea 
curing  this  task. 


lask  1.13  tevelop  Interim  DATANET  d6Uu  Software  to  Support  SF£F 
Interrace  to  the  Kernel 

Testing  or  various  implemicntat ion  pnases  of  tne  security  kernel 
r.iUSt  croceeo  oefore  tne  planneo  completion  of  the  SFEP. 
Tnererore,  tne  existing  i.ultics  DATAnLT  obuO  software  may  bo 
moi-iirieo  to  support  tne  interraces  to  tne  i^ultics  security 
Kernel,  as  aefinoo  unoer  Task  1.11,  so  that  the  functions  of  the 
security  Kernel  can  ce  confirmoa.  Formal  specifications  for 
tnese  aiooir  ications  ano  cor  rosponconce  proofs  will  not  bo 
prepareo  since  tnis  is  an  interim  solution  to  handing  tne  SFEP 
interrace  to  tne  security  kernel. 

Tne  prime  purpose  or  tnis  task  is  to  oecouple  the  DATANLT  oouu 
communications  interrace  rrom  tne  nultics  kernel  anc  SFEP  kernel 
oeveiopruenc  errorts  ror  as  long  as  possible.  This  approach 
minimizes  potentially  uncesirado  copenoencies  between  tne 
iiuitics  anu  oFc,P  oevelopmont  efforts.  Tne  intent  of  tnis  task  is 
not  to  recoue  tne  DATANLT'  ouuu  software  cut,  rather  to  covclcp  an 
interim  interface  to  tne  SFEP  Kernel  oy  mccifying  Multics 
couu..un ications  software  anc/or  tne  CATAhLT  uouO  softv;aro  to 
support  tne  reguireo  interim  interface  to  tne  SrEP  kernel.  Tnese 
li.ouir  ications  will  be  those  necessary  to  cemonstrate  tne 
Kcrnei/ncn-Ker nel  interface  on  the  blbU  processor  as  well  as 
simulate  tne  Kernel  to  kernel  interface  to  the  SFEP. 

wesign  memos  aescribing  the  moc-ifications  to  tne  Multics  DAT/\NET 
obuu  software  v/ill  ce  proparea  curing  this  task.  These 
mooir ications  will  ce  liiTiiteo  to  those  necessary  to  demonstrate 
tne  Ker nei/non-ker nel  interface  on  tne  OlbU  processor. 


lasK  1.14  preliminary  nultics  Kernel  Hoaule  Specifications  and 
ces ign 

inis  taSK  will  tuKe  tiie  formal  specifications  of  the  lovjer-lcvels 
of  ci'ie  security  Kernel  anu  convert  tnem  into  calling  sequences 
anu  argument  cescriptior.s  tor  each  mooule  in  preparation  for  tne 
first  imiplementation . 
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Task  1.15  Redesign  and  Informal  Description  of 
Supervisor  Functions 


Non-Kernel 


This  task  involves  modifying  all  supervisor  interfaces  that  were 
affected  by  the  kernel  design.  Good  engineering  pra'c  tice 
requires  many  of  these  interfaces  to  be  protected  from  tampering 
by  the  user  for  denial  of  service  considerations.  The  task  also 
involves  the  mapping  of  the  current  Multics  user  interface  into 
new  supervisor  functions  or  into  direct  kernel  interfaces. 

An  informal  description  of  the  nonkernel  supervisor  design 
revisions  will  be  prepared  during  this  task. 


T^k  1.16  Restructuring  System  Services 

The  current  Multics  system  provides  some  system  support  functions 
which  are  logical  extensions  of  the  ring  zero  kernel.  They  are 
implemented  as  separate  processes  which  are  trusted  to  support 
the  security  model  rules  for  access,  but  must  be  able  to  operate 
outside  the  security  access  constraints  of  the  kernel.  Some 
examples  of  these  are:  Answering  Service,  backup  and  retrieval, 
and  system  I/O. 


This  task  will  examine  these  trusted  processes  to  find 
alternative  ways  to  provide  their  functions  with  less  privilege. 
The  IPC  and  message  facilities  which  allow  users  of  all  security 
levels  to  communicate  with  each  other  and  with  the  trusted 
processes  will  be  examined  for  inclusion  in  the  kernel  design. 
The  device  and  demountable  media  resource  control  mechanisms  will 
be  restructured  to  account  for  the  access  rules  of  the  model. 


Honeywell  will  prepare  informal  design  memos  describing  each  of 
the  system  services  that  are  restructured  as  part  of  this  task. 


Task  1.17  Preliminary  Multics  Kernel  Implementation 

This  task  covers  the  coding  and  testing  of  the  kernel  for  the 
first  demonstration  system.  Each  of  the  kernel  modules  defined 
under  Tasks  1.7,  1.9,  and  1.14  will  be  coded  in  the  PL/I  or;  ALM 
languages.  Many  of  the  modules  may  be  variations  of  existing 
ring  zero  modules.  As  much  of  the  existing  code  will  be  used 
during  this  implementation  as  possible. 


Task  1.18  Implementation  of  the  Non-Kernel  Supervisor  Functions 
for  the  Preliminary  Multics  System 


This  task  runs  in  parallel  with  the  f 
implementation  and  includes  the  coding 
nonkernel  supervisor  modules  which  were  de 
1.16.  All  coding  will  be  done  in  the  PL/I 


irst  prototype  kernel 
and  testing  of  those 
fined  in  Tasks  1.15  and 
or  ALM  languages  and 
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much  of  the  existing  Multics  supervisor  code  will  be  used. 


Task  1.19  Integration  of  the  Preliminary  Multics  System 

This  task  is  the  first  attempt  to  bring  together  the  kernel  and 
nonkernel  supervisor  functions  and  the  interim  DATANET  6600 
software  to  support  the  user  interface  of  the  current  Multics 
system.  At  the  completion  of  this  task,  the  first  Multics  system 
based  on  a security  kernel  will  be  demonstrated. 


Task  1.20  Module  Descriptions 
Hardcore  Supervisor  Functions 


for  the  Kernel  and  Non-Kernel 


Module  descriptions  for  all  hardcore  supervisor  programs  will  be 
prepared  using  the  tools  and  techniques  developed  under  Task  1.2 
for  correctly  documenting  program  modules.  These  descriptions 
will  detail  the  final  program  calling  sequences  and  argument 
descriptions . 

The  module  descriptions  together  with  the  formal  kernel 
specification  and  the  nonkernel  supervisor  revisions  will  form 
tbe  complete  documentation  of  the  kernel-based  hardcore 
supervisor . 


Task  1.21  Performance  Studies,  New  Metering  Tools,  Test  Plans 
and  Reports 

This  task  is  responsible  for  estimating,  measuring  and  reporting 
on  the  performance,  compatibility  and  security  of  ttie 
kernel-based  Multics  system  through  all  three  demonstration 
versions . 

Useful  measures  of  performance,  compatibility  and  security  will 
be  defined.  Estimates  of  goals  to  be  attained  in  each  of  these 
areas  will  be  made.  Measurements  or  estimates  of  progress  toward 
these  goals  will  be  prepared  for  inclusion  in  periodic  status 
reports. 

This  task  will  define  new  metering  tools  which  can  be  included 
within  the  kernel  and  the  nonkernel  supervisor  to  determine  how 
the  system  is  performing  after  its  initial  implementation  and 
system  integration.  It  will  involve  detailed  examination  of  the 
design  decisions  in  the  development  of  the  modules  within  the 
kernel  and  within  the  nonkernel  supervisor  to  determine  their 
impact  on  overall  system  performance.  The  results  will  be  used 
during  the  recoding  of  the  kernel  for  the  third  demonstration 
(see  Task  1.24).  A report  describing  the  performance  studies, 
metering  tools,  and  estimates  on  performance  of  the  kernel-based 
system  will  be  prepared  prior  to  the  first  demonstration. 
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Plans  for  each  of  the  three  system  demonstrat 
prepared  for  Air  Force  review  and  approva 
outline  the  procedures  to  be  followed  dur 
performance  measurements  to  be  made,  and 
demonstrate  the  expected  degree  of  compatibil 
each  of  the  three  demonstration  tests  will 
report  within  60  days  following  the  test. 
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After  completing  the  third  demonstration  test,  a comprehensive 
report  covering  the  entire  project  will  be  prepared.  This  report 
will  describe:  design  goals  of  the  project,  system  architectural 
design  decisions,  evolution  of  the  kernel-based  Multics,  test 
results,  system  performance,  compatibility  between  the 
operational  prototype  secure  Multics  and  the  standard  Multics 
systems,  the  criteria  for  certification,  and  how  the  kernel-based 
Multics  system  meets  the  certification  criteria. 


Task  1.22  Extend  Multics  to  Support  the  SFEP 


when  the  detailed  design  of  the  SFEP  is  completed,  final  work  on 
the  Multics  support  for  the  SFEP  can  begin.  Also,  the  kernel 
interface  to  the  SFEP  can  be  refined  from  the  original  DATANET 
6600  interim  design  to  the  final  SFEP  design.  This  will  be  done 
in 'preparation  for  the  second  demonstration.  Also,  see  Task  1.13 
above  which  describes  this  interim  interface. 


This  task  covers  the  design  and  implementation  of  changes  to  the 
kernel,  the  nonkernel  supervisor,  the  administrative  functions 
and  initialization  functions  to  support  the  SFEP.  The  formal 
specifications  of  the  kernel  modules  and  the  correspondence 
proofs  will  be  updated  as  necessary.  The  hardcore  supervisor 
module  descriptions  will  be  updated  to  include  the  complete  SFEP 
interface . 


Task  1.23  Integrate  the  Preliminary  Multics  System  with  the  SFEP 

This  task  covers  the  system  tests  to  checkout  the  SFEP  on  the 
kernel-based  Multics  system.  At  the  completion  of  this  task,  the 
second  system  will  be  ready  for  demonstration. 

Task  1.24,  Recode  the  Kernel  in  the  System  Programming  Language 
and  Integrate  Performance  Improvements 

The  demonstration  of  the  first  system  will  show  the'  feasibility 
of  the  kernel  interfaces  and  the  restructuring  of  the  Multics 
supervisor.  The  next  major  step  toward  certification  will  be  to 
show  the  correspondence  between  the  formal  module  descriptions 
and  the  implementation  language. 
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To  accomplish  this,  the  kernel  modules  must  be  recoded  in  the 
system  programming  language  developed  under  Task  1.1.  All 
recoding  will  be  done  at  the  secure  Mul tics  installation  (see 
Task  1.30)  by  a special  group  of  system  designers  who  are  cleared 
to  Top  Secret.  All  formal  specifications,  module  descriptions, 
program  listings  and  test  data  from  the  first  and  second 
demonstration  systems  will  be  available  to  the  system  designers 
at  the  secure  site.  Any  program  listings,  specifications  or 
machine  readable  information  (e.g.,  system  tapes,  card  decks  or 
dump  tapes)  prepared  at  the  secure  site,  other  than  the  protected 
copies,  may  be  freely  removed  and  will  be  unclassified. 

Wnile  the  kernel  modules  are  being  recoded,  they  will  be  examined 
for  performance  improvements  based  on  the  study  results  in  Task 
1.21.  These  performance  improvements  will  be  incorporated  where 
appl icable . 

The  formal  kernel  specifications  and  correspondence  proofs  will 
be  updated  as  needed.  The  kernel  module  descriptions  will  be 
revised . 


Task  1.25  Revise  the  Non-Kernel  Supervisor  for  Performance 
Improvements 

The  performance  studies  described  in  Task  1.21  will  show  some 
areas  outside  the  kernel  which  adversely  affect  performance. 
Tnese  areas  will  be  redesigned  for  performance  improvements  in 
parallel  with  the  recoding  of  the  kernel. 

This  task  covers  the  redesign  to  implement  these  performance 
enhancements.  Tne  revisions  for  the  nonkernel  supervisor  will  be 
updated  and  the  module  descriptions  will  be  revised  as  needed. 


Task  1.26  Integrate  the  Re-implemented  Kernel  and  Supervisor 
Functions 

The  revisions  to  the  kernel  made  under  Tasks  1.24  and  1.25  will 
be  integrated  into  the  complete  operational  prototype  secure 
Multics  system  to  form  the  basis  for  the  third  demonstration. 

Initial  integration  testing  will  be  done  at  the  Honeywell 
non-secure  development  site,  using  a copy  of  the  kernel  produced 
at  the  secure  development  site  (see  Task  1.30).  All  changes  to 
the  kernel  will  be  made  by  cleared  system  designers  at  the  secure 
site  to  maintain  the  integrity  of  the  kernel.  Final  development 
testing  and  the  demonstration  test  will  be  performed  at  the 
secure  site  using  real  classified  data  and  a group  of  cleared 
users  requiring  classified  data  processing. 

This  task  covers  the  integration  and  system  tests  to  demonstrate 
the  kernel-based  Multics  system  that  is  to  be  certified.  The 
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results  of  this  effort  will  be  the  third  demonstration  system. 


Task  1.27  Program  Correctness  Proofs 

After  both  the  SFEP  and  Multics  kernels  have  been  recoded  in  the 
appropriate  system  programming  language,  the  correctness  proof 
techniques  developed  under  Task  1.5  and  Task  3.4  will  be 
applied.  Correctness  proofs  and  correspondence  to  the  formal 
specifications  for  kernel  program  modules  will  be  accomplished  at 
the  source  code  level  only.  Correctness  proofs  of  program  object 
code  is  beyond  the  scope  of  this  effort. 
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chnical  report 

describing  th 

e 

work  on 

final 

cer tif ic 

ation 

will 

be  prepared. 

A review  of  the  progress  on  this 

task  will  be 

held 

abou  t 

three 

(3) 

months  after  it 

s start. 

Task  1.28  Develop  an  ARPA  Network  Capability  for  the  Operational 
Prototype  Multics  System 

Multics  development  sites  currently  provide  the  capability  to  use 
the  ARPA  network  with  a special  hardware  and  software  interface 
to  an  ARPA  network  Interface  Messaqe  Processor  (IMP)  computer. 
At  the  present  time,  this  capability  is  not  part  of  the  standard 
Multics  product. 


This  task  will  utilize  the  technology  and  software/hardware 
design  of  the  current  ARPA  network  interface  to  develop  an  ARPA 
network  capability  for  the  secure  Multics  demonstration  system. 
The  current  host  to  IMP  protocol  will  be  used.  The  actual 
network  connection  will  be  through  the  SFEP.  The  ARPA  network  is 
not  physically  secure  and  does  not  provide  logical  identification 
of  security  classification  for  messages.  Therefore,  a multilevel 
security  interface  cannot  be  provided.  However,  the  design  will 
not  preclude  future  multilevel  operation  from  being  implemented 
if  a secure  interface  for  the  ARPA  network  is  eventually  defined. 
Any  changes  to  the  ARPA  network  protocols  are  beyond  the  scope  of 
this  task.  An  implementation  plan  and  design  specification  will 
be  prepared.  The  ARPA  network  software  (and  possibly  hardware) 
designed  under  this  task  will  be  integrated  into  the  second  or 
third  demonstration  Multics  system  as  defined  in  the 
implementation  plan.  All  coding  will  be  done  by  cleared 
personnel  since  the  network  support  capability  must  be  integrated 
late  in  the  course  of  the  project.  Final  testing  will  be  done 
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US  mg 
1.30) 


the  ARPA  network  connection  at  the  secure  site  (see  task 


Task  1.29  Train  Cleared  System  Designers 

The  third  demonstration  kernel  software  will  be  developed  oy 
system  designers  with  Top  Secret  security  clearances.  Assuming 
clearable  trained  system  designers  would  not  be  available  with 
replacement,  this  task  provides  for  the  training  of  four  system 
designers  who  have  the  necessary  security  clearance.  They  will 
work  with  the  uncleared  system  designers  for  18  months  before 
beginning  the  recoding  of  the  kernel  for  the  third  demonstration 
system . 


Task  1.30  Secure  Site  Preparation 


A secure  Multics  system  installation  controlled  at  a security 
level  of  Top  Secret  is  needed  in  recoding  the  security  kernel  for 
the  tnird  demonstration  system.  Only  system  designers  cleared  to 
Top  Secret  can  be  allowed  to  recode  the  security  kernel,  if  the 
integrity  of  the  implementation  is  to  be  certified  to  this  level. 

This  task  covers  the  preparation  of:  the  physical  site,  tne 
hardware,  the  communications  systems,  the  operating  procedures, 
and  the  site  support  procedures.  This  task  also  provides 
specialized  training  for  site  support  personnel  in  the  operation 
and  maintenance  of  the  kernel-based  Multics. 


Th  e s 
secur 
which 
conta 
check 
pr  oce 
inter 
syste 
load 
they 


ecure  site  will  serve  as:  a secure  repository  of  tne 

ity  Kernel;  a secure  location  to  edit  and  compile  programs 
comprise  the  kernel;  a tool  for  generating  system  tapes 
ining  the  se 
out  of  interim 
ssing  Top  Se 


m 


using  the 


re  kerne 

1 ; a 

final 

deve 

lopraent 

test  si 

te  for 

kernel 

sol 

; twar e 

; a 

service 

site 

for 

et  data 

fo  r 

a gro 

up  of 

cleared 

users ; 

and  a 

ua  tion 

site 

for 

the 

third 

demonst 

r a tion 

roup  of 

cleared 

users 

as  a ba 

se  for 

system 

will  be 

divided  among 

these  ac 

t iv  i tie 

s when 

lusive . 

V 

of  this 

task  are: 

Work  w.ith  the  Air  Force  to  establish  a group  of  users  who 
need  to  do  Top  Secret  processing.  (one  year  in  advance 
of  the  third  demonstration  system.) 


b.  Work  with 
location . 


the  Air  Force  in  choosing  a secure  site 


Consult  on  the  preparation 
hardware  installation. 


of  the  secure  site  for 
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d.  Procure  the  Honeywell  Series  60  Level  68  (or  equivalent) 
hardware 


e.  Work  with  the  Air  Force  to  procure  an  ARPA  network  IMP 
and  communications  interface. 

f.  Define  site  operations  and  security  procedures. 

g.  Train  Top  Secret  cleared  Air  Force  operators  and 
communications  specialists. 

h.  Train  Top  Secret  cleared  Honeywell  Site  Analysts  and 
Field  Engineers. 


Ta  s k 1.31 


Conversion  Plan 


for  a Test  and 


Evaluation  Site 


This  task  will  develop  a detailed  plan  to  transfom  a site  (e.g., 
AFDSC)  from  an  operational  installation,  which  is  offering  the 
Multics  standard  system  as  a service,  to  a site  which  will 
provide  a kernel -based  Multics  system  for  test  and  evaluation. 
The  application  of  this  conversion  plan  will  be  as  follows: 

a.  Implement  the  conversion  plan  and  evaluate  the  conversion 
aids  at  the  secure  development  site. 

b.  Revise  the  secure  Multics  capability  at  the  secure 
development  site  as  necessary  and  modify  the  Conversion 
Plan  as  appropriate  for  Air  Force  concurrence. 

c.  Implement  the  plan  at  any  other  Multics  site  which  is  to 
be  used  for  a test  and  evaluation  of  the  kernel-based 
system . 

This  plan  will  first  review  current  operational  procedures  and 
then  identify  all  additional  hardware,  specialized  software  to  be 
implemented  and  exercised  (e.g.,  storage  system  conversions, 
etc.),  additional  documentation,  and  required  training  for  the 
changeover  of  a Multics  site  so  that  the  site  can  use  the 
kernel-based  Multics  system.  The  problem  of  reverting  a site 
back  to  support  of  standard  Multics  hardware  and  software  will 
also  be  addressed. 

The  primary  output  of  this  task  is  a detailed  Conversion  Plan. 


Task  1.32  Final  System  Evaluation  Test  Period 


After  the  successful  completion  of  the  third  demonstration,  the 
kernel-based  Multics  system  will  remain  operational  at  the  secure 
Multics  installation.  The  system  will  be  run  in  multilevel 
security  mode  with  users  chosen  by  the  Air  Force.  Uncleared 
users  will  be  allowed  to  use  the  system  only  if  approved  by  the 
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appropriate  Air  Force  authority.  Classified  data  processing  will 
be  done  on  a regularly  scheduled  basis  as  a Multics  service  site. 


Task  1.33  Study  Security  Vulnerability  due  to  Hardware  Failure 

Tne  purpose  of  this  task  is  to  identify  hardware  events  that 
result  in  a security  vulnerability  in  the  secure  Multics  system. 
For  this  task,  it  will  be  assumed  that  an  event  either  does  or 
does  not  result  in  a security  vulnerability.  That  is,  all 
security  vulnerabilities  are  considered  to  be  equally  serious.  A 
separate  task  may  be  established  later  to  assign  a "degree  of 
seriousness"  rating  to  each  security  vulnerability  event. 

The  previous  work  along  these  lines  for  the  Secure  Communications 
Processor  (SCOMF)  will  be  examined  and  the  methodology  will  be 
used  where  practical. 

The  output  of  this  task  will  be  a report  which  identifies  the 
security  vulnerability  events  and  discusses  the  criteria  and 
methodology  used  in  this  task. 


Task  1.34  Define  Hardware  Configuration  for  Probaoil istic 
Security  Analysis 

The  purpose  of  this  task  is  to  identify  equipment  for  which 
failure  rates  must  be  determined  and  to  provide  hardware 
configuration  inputs  to  the  model  that  will  calculate  the 
system's  probabilistic  vulnerability  rating  due  to  hardware 
failures.  Subtasks  include: 

a.  Identifying  the  equipment  that  will  be  in  the  Project 
Guardian  Multics  system  for  this  analysis. 

b.  Identifying  the  changes  that  will  be  made  to  existing 
equipment . 

c.  Determining  the  major  characteristics  of  the  new 
equipment.  This  includes  the  gross  implementation 
technology  and  approach. 

d.  Deciding  on  the  quantities  and  sizes  of  the  equipment 
that  will  comprise  a "typical"  or  base  system. 

The  scope  of  the  equipment  covered  by  this  task  ranges  from  the 

processor  to  peripneral  devices  and  the  SCOMP.  The  output  of 
this  task  will  be  a report  that  details  the  expected  composition 
of  the  Multics  system  to  be  used  in  the  verification  tasks  below 
(Task  1.35-Task  1.40) . 


31 


Task  1.35  Partition  the  Hardware  into  Functional  Blocks  for  the 
Security  Analysis 

In  order  to  evaluate  the  impact  of  certain  failures  in  the 
"security  sensitive"  portions  of  the  hardware,  it  is  necessary  to 
delineate  those  portions  of  the  hardware.  That  is  the  purpose  of 
this  task.  The  result  can  be  viewed  as  a detailed  block  diagram 
of  the  security  sensitive  hardware  in  a system,  although  the 
actual  results  may  be  in  a tabular  form,  and  not  necessarily  in 
conventional  block  diagrams. 

The  challenges  of  this  task  are  to  establish  a security  perimeter 
and  to  subdivide  the  portion  of  the  system  within  that  security 
perimeter  into  "suitably  sized"  blocks.  Their  functional  size 
must  be  appropriate  for  meaningful  use  in  other  tasks  related  to 
the  probabilistic  measure  of  security  vulnerabilities  due  to 
Hardware  failure.  Therefore,  part  of  this  task  involves 
developing  criteria  to  use  in  establishing  a security  perimeter 
and  in  subdividing  a large  computer  system  into  the  "appropriate" 
blocks . 

This  task  effort  will  include  examining  the  applicability  of 
reliability  studies  and  Failure  Modes  and  Effects  Analysis  (FMEA) 
studies  that  have  been  or  are  being  done  on  Honeywell  equipment 
used  in  Series  60/6000  systems.  Where  practical,  the 
methodologies  and/or  results  of  such  studies  will  be  applied, 
extended,  or  adapted  to  this  task's  needs. 

Task  1.36  Analysis  of  Hardware  Failure  as  A Security 
Vulnerability 

This  task  involves  deciding  whether  or  not  a security 
vulnerability  exists  for  each  failure  mode  of  each  functional 
block  of  the  hardware. 

The  speed  and  thoroughness  with  which  hardware  failures  are 
detected  is  an  important  aspect  of  deciding  whether  or  not  a 
failure  gives  rise  to  a security  vulnerability.  The  impact  of 
incomplete  failure  detection  may  be  lessened  by  periodically 
running  tests  which  verify  hardware  functions  that  may  be 
deficient  in  automatic  failure  detection.  These  considerations 
will  be  factored  into  the  security  vulnerability  assignments. 
Some  recommendations  may  be  made  for  hardware  changes  and/or  the 
running  of  periodic  "health  checks"  to  be  certain  that  internal 
hardware  failure  detection  is  completely  operational.  The  output 
of  this  task  will  be  a set  of  data  in  a database  that  is  used  by 
a later  task. 

This  task  includes  an  assessment  of  the  probable  effects  of 
transient  or  intermittent  hardware  failures,  as  well  as  solid 
failures.  The  results  of  this  task  may  suggest  recommendations 
as  to  hardware  functions  that  should  be  avoided  by  the  security 
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kernel.  These  will  be  factored  into  programming  standards  and 
language  tasks. 


Task  1.37  Determine  Hardware  Usage  Rates 

The  security  vulnerability  of  a portion  of  the  hardware  is 
directly  proportional  to  the  degree  to  which  that  portion  of  the 
hardware  is  utilized.  This  task  determines  the  usage  rates  for 
those  functional  hardware  blocks  whose  failure  may  give  rise  to  a 
security  violation. 

The  data  will  be  structured  to  reflect  the  variable  range  of  the 
usage  by  different  portions  of  the  software,  firmware,  and  the 
generic  actions  by  user  programs.  The  output  from  this  task  will 
be  a set  of  data  in  a database  that  is  used  by  a later  task. 

Accomplishing  this  task  will  require  extensive  hardware 
measurements  on  an  operational  system  plus  substantial  analysis 
of  how  the  software  uses  tne  hardware. 

However,  the  output  of  this  task  will  be  useful  for  m.uch  more 
than  analyzing  security  vulnerabilities.  Analysis  of  the  data 
gathered  during  this  task  will  disclose  ways  to  improve  system 
performance  by  different  utilization  of  the  existing  hardware, 
ways  to  change  the  hardware,  or  improvements  to  m.ake  in  the  next 
generation  of  hardware,  may  also  become  aoparent. 


Task  1.38  Determine  Failure  Rates  of  System  Components 

Much  raw  data  already  exists  for  the  equipm.ent  used  in  Multics 
systems  (i.e..  Series  60/6000).  This  task  involves  collecting 
existing  data,  identifying  portions  of  the  Multics  system  not 
covered  by  the  existing  data,  and  obtaining  suitable  data  for 
tnose  non-covered  portions  of  the  system.  The  data  will  be 
organized  in  a database  to  correspond  to  the  functional  model  of 
the  hardware  that  was  established  in  an  earlier  task  for  purposes 
of  evaluating  the  security  vulnerabilities.  (See  Task  1.36).  That 
is,  data  for  individual  piece  parts  (chips)  will  be  combined  to 
yield  data  for  a low-level  function  of  the  hardware  (e.g.,  an 
adder ) . 

The  data  will  also  be  structured  to  reflect  the  various  failure 
modes  tnat  are  of  importance  for  potential  security 
vulnerabilities.  This  data  base  will  be  refined  as  necessary 
during  the  life  of  the  project.  Sucn  refinements  are  expected  to 
be  minimal. 
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due 


to 


Task  1.39  Probability  of  Security  Vulnerabilities 
Hardware  Failures. 

This  task  combines  the  numerical  results  of  the  previous  tasks  to 
calculate  the  probability  of  security  vulnerabilities  due  to 
hardware  failures.  This  task  will: 

a.  Develop  computer  programs. 

b.  Establish  data  bases. 

c.  Exercise  the  programs. 

d.  Collate  the  results 

The  output  of  this  task  will  be  a report  that  summarizes  the 
calculation  methodology,  summarizes  the  content  of  the  data 
bases,  and  presents  the  numerical  results  of  performing  the 
calculations. 


Task  1.40  Assess  Other  Probabilistic  Security  Vulnerabilities 

This  task  involves  identifying  situations  or  events  other  than 
hardware  failures  which  are  of  a probabilistic  nature  and  can 
lead  to  security  violations.  The  impact  of  such  events  and 
situations  will  then  be  evaluated.  The  only  candidate  identified 
so  far  for  this  task  is  falsified  authentication  of  users 
(password  guessing). 

The  output  from  this  task  will  be  a report  that  identifies  the 
situations  and  the  security  vulnerability  probabilities. 


Resource  Requirements 

The  following  table  indicates  the  resource  requirements  necessary 
for  the  subtasks  of  Task  1.0. 
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Section  II 


Secure  Front-End  Processor  Hardware 


Introduction  and  Overview 

Tnis  task  produces  the  liardware  base  for  a Secure  Front-End 
Processor  (SFEP) . The  basic  technical  approach  for  the  SFEP 
hardware  design  is  to  expand  the  selected  minicomputer  now  in 
development  within  Honeywell  for  applications  to  include  an 
essentially  autonomous  Security  Protection  Module  (SPM).  The 
extended  minicomputer  can  be  used  in  a stand-alone  environment 
and  is  then  known  as  a Secure  Communications  Processor  (SCOMP)  . 
The  SPM,  when  integrated  into  the  minicomputer,  will  provide  the 
hardware  controls  necessary  for  a Secure  Communications 
Processor.  When  an  interface  unit  for  a host  6000/Series  60 
computer,  a TEMPEST  unit,  and  selected  peripherals  are  added,  the 
required  Secure  Front-End  Processor  results. 

Secure  Front-End  Processors  are  required  for  large-scale  systems 
to  extend  the  security  perimeter  to  include  external 

communications  and  input/output  facilities.  This  part  of  the 
Integration  Plan  encompasses  the  design,  development,  and 

fabrication  of  two  Secure  Front-End  Processors  for  eventual 
integration  into  hardware  configurations  for  hardware  testing, 
SFEP  software  development,  and  an  operational  prototype  secure 
Multics  system. 

This  effort  will  complete  tne  design,  fabrication,  integration, 
and  test  evaluation  of  SFEP  hardware  prototypes.  Specific  tasks 
ar  e : 

a.  Design,  development  and  fabrication  of  Security 
Protection  Modules  and  6000/Series  60  Interface  Units  to 
permit  the  integration  of  modified  minicomputers  into 
large  scale  systems  to  function  as  Secure  Front-End 
Processors  (SFEP)  . 

b.  The  design  and  fabrication  of  modules  and  components 
required  for  TEMPEST  compatibility. 

c.  The  fabrication  of  a non-r uggedi zed  developmental  SFEP 
unit  to  serve  as  a hardware  and  software  checkout, 
development,  and  demonstration  facility. 

d.  The  fabrication  of  a ruggedized  prototype  SFEP  unit  for 
TEMPEST  qualification  testing  and  Muitics  integration 
tes  ts . 
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Task  2.1  Security  Protection  Module  (SPM)  Design 

The  SPM  is  an  address  translation  unit  necessary  to  support  the 
access  control  requirements  of  a security  kernel.  It  is  an 
autonomous  m.odule  which  can  be  integrated  into  the  minicomputer 
to  provide  segmented  addressing  on  a per  process  basis. 

The  SPM  contains  a fast-access  cache  memory  for  storage  of  data 
descriptors  and  related  access  privileges,  provisions  for 
multiple  machine  states  (rings  of  protection),  storage  for  access 
and  call  brackets,  fault  directing  vectors  and  related  controls 
necessary  to  support  the  Reference  Monitor  concept. 

The  SPM  design  task  includes  the  following  subtasks:  detailed 
logical  design,  mechanical  design,  documentation,  parts 
selection,  development  and  product  specifications,  and  support  to 
design  verification  and  SPM  evaluation  tests.  The  output  from 
this  task  will  be  the  design  documentation  which  will  permit 
fabrication  of  the  SPM. 


Task  2.2  6000/Series  60  Interface  Unit  Design 

The  6000/Series  60  Interface  Unit  (lU)  is  required  to  provide  the 
hardware  interface  for  the  SFEP  into  a large-scale  host 
{6000/Series  60)  computer  system.  The  lU  provides  a local 
bi-directional  communications  channel  up  to  2000  feet  in  length 
between  the  SFEP  bus  and  the  Direct  Channel  connection  of  the 
6000/Series  60  lOM. 

The  6000/Series  60  lU  design  task  includes  the  following 
subtasks:  logic  board  design,  backplane  design,  chassis  design 
documentation,  parts  selection,  development  and  product 
specifications,  and  support  to  lU  evaluation  tests.  The  output 
from  the  6000/Series  60  lU  design  task  will  be  the  documentation 
which  will  permit  fabrication  of  tne  6000/Series  60  lU. 


lask  2.3  SCOMP  Design 

The  SCOMP  design  task  encompasses  the  design  activities  required 
to  modify  a commercial  minicomputer  to  interface  with  a SPM  and 
lU  and  the  preparation  of  test  plans  to  be  used  in  the  SPM  and  lU 
evaluation . 

The  SCOMP  design  tasks  include  the  following  subtasks:  the  design 
and  documentation  of  the  CPU  hardware  and  firmware  modifications, 
the . formula tion  of  a master  test  plan,  an  SPM  development  test 
plan  and  procedures  and  an  internal  acceptance  test  plan. 

\ 

The  output  from  the  SCOMP  design  task  will  be  the  documentation  ' 
required  to  modify  the  CPU,  test  the  SCOMP,  and  evaluate  the  SPM 
design. 
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Task  2.4  Test  and  Evaluation  Software  Design 

Test  and  evaluation  software  is  required  to  permit  separate 
testing,  verification,  and  evaluation  of  all  functions  designed 
into  the  SFEP  hardware  via  the  SPM  and  6000/Series  60  lU. 

This  software  will  provide  routines  which  exercise  descriptors 
(cache).  Descriptor  Base  Registers  (DBR)  , all^  SPM  control 
operations,  and  ring  controls.  In  addition,  test  and  evaluation 
software  which  exercises  the  security  functions  of  the  secure 
minicomputer  will  be  developed  and  will  support  intraprocedure, 
interprocedure,  intraprocess  and  interprocess  context  switching, 
I/O  control  and  access  control  procedures.  Additional  software 
will  exercise  the  operation  of  the  6000/Series  60  lU  in  a 
closed-loop  (i.e.,  wrap-around)  manner. 

Tne  test  and  evaluation  software  design  task  will  be  based  on  a 
software  specification  of  the  secure  computer  functions  to  be 
derived  from  the  SFEP  hardware  Functional  Specification.  This 
software  will  be  developed  using  the  simulator  defined  in  Task 
3.5  and  will  form  the  basis  for  any  diagnostic  or  acceptance  test 
software  developed.  This  task  includes  the  design,  coding, 
checkout,  and  documentation  of  the  Test  and  Evaluation  software. 


Task  2.5  Test  Equipment  Design 

Tne  development  of  test  equipment  is  required  to  permit 
evaluation  and  acceptance  testing  of  the  hardware  subsystems. 

Three  items  of  test  equipment  are  required: 

a.  History  Memory 

b.  ID  Wrap-Around  Unit 

c.  TEMPEST  Test  Fixture 

The  History  Memory  is  a module  that  plugs  into  the  bus  and 
selectively  stores  bus  cycles.  Used  in  conjunction  with  the  Test 
and  Evaluation  (T  and  E)  software,  or  any  special  diagnostic  or 
evaluation  software,,  the  History  Memory  provides  a powerful 
diagnostic  aide,  particularly  during  initial  debug  or  with  low 
frequency  failures,  by  providing  a history  of  the  data,  address 
and  controls  of  the  bus  cycles  prior  to  and  during  an  event. 

The  lU  Wrap-Around  Unit  is  used  at  the  SFEP  software  development 
facility  to  provide  the  capability  for  dynamically  testing  the 
6000/Series  60  lU.  This  unit  will  temporarily  store  data  that  is 
output  to  it,  then  transmit  the  data  back  to  the  SFEP  for 
checking.  Thus  providing,  in  conjunction  with  the  T and  E 
software,  a means  of  checking  out  the  lU  prior  to  integration 
with  a host  computer. 
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The  TEMPEST  test  fixtures  are  plates  and  fixtures  used  during  the 
TEMPEST  qualification  test  (Task  2.12). 

The  test  equipment  task  includes  the  design,  documentation, 
fabrication  and  checkout  of  the  test  equipment  specified. 


Task  2.6  Design  Verification 

This  task  is  necessary  to  verify,  with  confidence,  that  the 
design  objectives  for  security  compromise  probability  which  will 
be  less  than  .000001  have  been  met.  This  task  will  also  verify, 
with  confidence,  that  the  SCOMP  hardware  design  functions  exactly 
as  specified  (i.e.,  there  are  no  security  breach  paths).  This 
task  includes  two  subtasks: 

a.  Probabilistic  measure  of  security  compromise  due  to 
hardware  failures.  This  task  resembles  a "failure  mode 
and  effects"  analysis  on  those  components  whose  failure 
may  jeopardize  security.  A baseline  SFEP  configuration 
is  analyzed  against  defined  hardware  security  breach 
categories. 

b.  Electrical  and  Logical  design  verification.  This  task 
will  verify,  with  confidence,  via  computer  simulations, 
computer  analysis  and/or  algorithmic  evaluations,  that 
the  electrical  and  logic  design  is  complete. 

The  output  from  these  tasks  will  be  probabilistic  and  confidence 
measures.  These  outputs  may  dictate  design  modification  and/or 
redundancy  in  critical  paths.  The  need  for  and  frequency  of 
"health  checking"  software  will  be  defined  by  the  analysis.  The 
analysis  will  be  documented  in  a final  report. 


Task  2.7  Communications  Interface 

This  task  will  determine  additional  requirements  for  the 
communications  interface.  Additional  studies  will  be  performed 
which  delineate  hardware,  logical,  and  software  interfaces. 

This  task  will  study,  as  applicable,  standard  communications 
interfaces  including  AUTODIN  II,  the  DCW  communications 
controller  and  the  ARPA  networks  resulting  in  a final  report 
which  summarizes  any  additional  communications  interface 
requirements. 


Task  2.8  SFEP  Development  Unit 

This  task  will  develop  the  first  testable  SFEP  hardware. 
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The  task  consists  of  procurement,  fabrication,  assembly,  and  test 
of  the  SFEP  development  unit.  The  efforts  included  in  this  task 
are  listed  below: 

a . SCOMP 

1.  Procure  minicomputer  and  peripherals 

2.  Procure  additional  processor 

3.  Perform  modifications  to  processors 

4.  Fabrication/assembly  of  two  sets  of  SPM  boards 

5.  Assemble  SCOMP 

6.  SCOMP  integration  and  test 

b.  6000/Series  60  lU 

1.  Procure  chassis  and  power  supply 

2.  Fabrication/assembly  of  6000/Series  60  lU  boards 

3.  6000/Series  60  lU  integration  and  test 

c.  System  Integration 

1.  Assemble  SCOMP  to  6000/Series  60  lU  cables 

2.  Integrate ■ SCOMP  and  6000/Series  60  ID 

3.  Test 

Completion  of  the  design  and  development  tasks  (Tasks  2.1  - 2.5 

above)  will  provide  the  necessary  documentation  to  fabricate  the 
SFEP  development  unit. 

The  output  of  this  task  will  be  a SFEP  unit  for  use  in  the  SFEP 
hardware  and  software  development  site  and  a vehicle  for  the  SFEP 
demonstration . 


Task  2.9  SPM  Development  Tests 

This  task  consists  of  a series  of  tests  which  are  conducted  per 
the  plans  and  procedures  developed  under  Task  2.3.  The  purpose 
of  these  tests  are  to  evaluate  the  utility,  performance,  and 
margins  of  the  SPM  design.  Alternative  implementations  of 
various  SPM  functions  will  be  assessed.  The  output  from  this 
task  will  be  a test  report  and  a preferred  SPM  design  for  printed 
circuit  board  development  and  Programmable  Read-Only  Memory 
(PROM)  firmware. 
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Task  2.10  Printed  Circuit  Board  Design 

The  objective  of  this  task  is  to  convert  the  SPM  boards,  that  are 
wirewrapped  or  hardwired,  into  printed  circuit  boards  prior  to 
fabrication  of  the  prototype  unit. 

This  task  will  generate  production  documentation  for  printed 
circuit  boards  for  the  SPM.  The  basic  subtasks  are:  layout, 
checking,  digitizing,  photo  plotting,  printed  circuit  board 
detail  drawing,  and  producing  assembly  drawings.  This  task 
begins  when  the  design  and  testing  of  the  SPM  boards  are 
considered  complete.  The  output  of  this  activity  is  production 
documentation  for  the  SPM  boards. 


Task  2.11  TEMPEST  Compatibility  Design 


TEMPEST  compatibility  design  is  required  to  meet  the  Red/Black 
separation  and  other  TEMPEST  requirements. 


This  task  includes  the 
requirements,  strippers 
design,  chassis  des 
documentation.  The  o 
documentation  which 
TEMPEST-related  compone 


following  subtasks:  development  of 

and  filters  design,  printed  circui 
ign,  test  software  routines, 
utput  from  this  task  will  be  the 
will  permit  the  fabricatio 
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Task  2.12  TEMPEST  Qualification  Test 

This  task  will  demonstrate  compliance  of  the  SEEP  hardware  to  the 
TEMPEST  requirements  as  defined  in  Task  2.6  above.  The  tests 
will  be  performed  in  simulated  operational  environments. 
Conducted  and  radiated  emanations  will  be  measured  and  correlated 
utilizing  TEMPEST  test  equipment.  This  task  will  be  based  on  a 
TEMPEST  Test  Plan. 

The  following  subtasks  are  included:  test  plan  development, 
qualifications  test  performance,  and  results  analysis.  Results 
of  the  qualification  test  and  analysis  will  be  documented  in  a 
test  report. 

Task  2.13  . SFEP  Prototype  Unit 

This  task  consists  of  the  procurement , fabrication,  assembly  and 
test  of  the  SFEP  prototype  unit.  The  SEEP  prototype  will  be  c. 
ruggedized  unit  that  includes  TEMPEST  hardware.  This  computer 
will  be  used  for  TEMPEST  qualification  testing  and  will  be  the 
SFEP  unit  delivered  for  eventual  Multics  integration. 

The  efforts  included  in  this  task  are  listed  below: 
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SCOMP 


a . 

1.  Procure  minicomputer 

2.  Perform  modifications  for  ruggedi zation 

3.  Fabrication/assembly  of  SPM  boards 

4.  Assemble  SCOMP 

5.  SCOMP  integration  and  test 

b.  6000/Series  60  lU 

1.  Procure  ruggedized  chassis  and  power  supply 

2.  Fabrication/assembly  of  6000/Series  60  lU  boards 

3.  Assemble  6000/Series  60  lU  unit 

4.  6000/Series  lU  integration  and  test 

c.  Additional  Hardware  to  Meet  TEMPEST  Requirements 

1.  Fabricate  soecial  chassis 

2.  Procure  power  supplies 

3.  Procure  components 

4.  Procure  circuit  boards 

5.  Assemble  TEMPEST  unit 

6.  TEMPEST  integration  and  test 

d.  System  Integration 

1.  Assemble  (cable)  SFEP  prototype  unit 

2.  Test  unit 

Completion  of  the  fabrication,  assembly,  and  test  portions 
this  task  will  result  in  a completed  prototype  hardware  unit 
forms  a Secure  Front-End  Processor  with  TEMPEST  capability. 


Task  2.14  Delivered  Unit  Support 


This  task  includes  installation  and  integration  of  deliv 
equipment  for  use  in  the  secure  computer  development  site 
includes  unit  installation  and  test,  continued  field  support 
maintenance,  and  reissued  spare  hardware  materials. 
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Resource  Requirements 

The  following  table  indicated  the  resource  requirements  necessary 
for  the  subtasks  of  Task  2.0. 


I 
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Section  III 


Secure  Front-End  Processor  (SFEP)  Software  Development 

This  section  describes  the  tasks  required  to  develop  the 
certifiably  secure  software  system  for  a front-end  communications 
processor.  This  software  will  consist  of  two  major  components: 
a general  purpose  security  kernel  suitable  for  secure 
communications  processor  applications,  and  the  necessary 
operating  system/application  software  to  perform  the  Multics 
front-end  processor  functions. 

To  support  the  development  of  this  software  system  and  to 
accomplish  the  certification  of  the  security  kernel,  it  is 
necessary  to  define  specification  and  programming  standards, 
establish  procedures  and  maintenance  tools  for  certification, 
define  modifications  to  existing  programming  languages,  and 
develop  test  and  evaluation  methods  for  secure  computer  systems. 
Fortunately,  many  of  these  items  can  benefit  from  similar 
activities  carried  out  for  the  Kultics  security  kernel 
development.  The  SFEP  software  development  will,  where 
practical,  use  the  same  languages,  standards,  procedures,  etc.  as 
are  used  for  Multics.  Only  where  necessary  will  special 
standards  and  procedures  be  developed  for  SFEP. 

The  SFEP  software  development  proceeds  through  a series  of  steps 
that  allow  measurement  of  progress  against  the  proposed  plan. 
First,  formal  specifications  for  the  security  kernel  will  be 
developed,  reviewed  with  the  Air  Force  and  submitted  to  the 
certification  process.  In  parallel  with  the  certification 
process,  a prototype  kernel  and  SFEP  operating  system/application 
software  will  be  implemented  in  assembly  language.  This  assembly 
language  software  package  will  be  used  to  demonstrate  a 
free-standing  capability.  By  this  time  the  correspondence  proofs 
of  the  formal  kernel  specifications  will  have  been  completed. 
Factoring  in  the  lessons  learned  from  the  specification  proof 
activity  and  from  the  prototype  kernel  development,  a formal 
kernel  will  be  developed  in  a modified  PL/1  language.  This 
kernel  will  be  integrated  with  other  SFEP  software  and  used  in 
the  intermediate  Multics  demonstration  that  integrates  Multics 
and  the  SFEP.  Kernel  certification  (high  level  language)  will  be 
carried  out  in  parallel  with  the  integration  under  Task  1.27. 
Next,  any  changes  required  as  a result  of  the  certification  and 
integration  efforts  will  be  made.  This  includes  enhancements  for 
performance  and  functionality.  Finally,  the  SFEP  is  again 
integrated  with  Multics  for  the  prototype  demonstration. 

The  SFEP  software  development  activity  is  subdivided  into  nine 
tasks.  Task  3.1,  3.2  and  3.3  outline  the  required  effort  to 
produce  the  software  for  both  the  prototype  and  formal  kernel. 
Tasks  3.4,  3.5  and  3.6  provide  the  necessary  tools  to  support 
certification  efforts  and  overall  software  program  development. 
Tasks  3.7  and  3.8  describe  the  efforts  required  to  produce 
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software  that  will  suport  a Multics  front-end  application.  Task 
3.9  is  concerned  with  evaluating  and  testing  the  total  software 
for  both  the  prototype  and  formal  systems.  The  effort  described 
by  these  tasks  is  an  estimate  of  what  is  required  to  develop  a 
certified  secure  SFEP  software  system.  It  is  expected  that  as 
the  certification  technology  evolves,  changes  may  be  required  to 
the  described  approach. 


Task  3.1  Top  Level  Kernel  Specifications 

This  task  will  produce  the  formal  specifications  for  a general 
purpose  security  kernel  suitable  for  secure  communications 
processor  applications.  Both  the  top  level  specification  and  the 
lower  level  hierarchical  specifications  will  be  generated. 

The  impact  on  efficiency  and  certif iabil ity  of  SFEp  architecture, 
communications  processing  functions  and  the  SFEP  to  Multics 
interface,  will  be  factored  into  the  development  of  these 
specifications.  However,  where  practical,  these  specifications 
will  be  similar  to  the  Multics  kernel  specifications,  both  in 
functions  covered  and  in  the  specification  language  used.  Of 
course,  the  SFEP  kernel  functionality  is  expected  to  be  less  than 
that  of  Multics. 

The  top  level  specification  (TLS)  covers  the  kernel 's  interface 
with  the  operating  system/applications  software.  The  preliminary 
version,  submitted  in  February,  1976,  for  Air  Force  review,  will 
form  the  basis  for  work  in  this  area.  Additional  effort  under 
this  task  includes  the  revision  of  the  TLS  on  the  basis  of  Air 
Force  review,  identification  of  trusted  processes,  and  resolution 
of  open  issues. 

It  is  assumed  that,  trusted  processes  are  outside  the  distributed 
kernel,  but  are  included  within  the  security  perimeter.  That  is, 
they  must  be  proven  correct  as  part  of  the  certification  task. 
For  convenience,  the  development  of  trusted  processes  are 
included-  in  their  respective  functional  areas,  i.e.,  either  as 
part  of  the  operating  system  or  the  communication  subsystem. 

The  TLS  will  be  extended  to  lower  levels  to  include  all  modules 
in  the  security  perimeter  (i.e.,  distributed  kernel  and  trusted 
processes ) .' 

To  'achieve  a reasonable  development  schedule,  work  on  the  lower 
level  specifications  must  start  before  the  top  level 
correspondence  proofs  have  been  completed.  The  risk  in  this 
early  start  (due  to  certification  related  changes)  will  be 
minimized  by  submitting  the  top  level  specifications  for  Air 
Force  review  prior  to  starting  on  the  lower  level  specifications. 
A formal  Preliminary  Design  Review  (PDR)  will  be  held  after 
comoletion  of  the  too  level  correspondence  proofs  done  in  Task 
3.4. 
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These  formal  specifications  will  serve  as  the  basis  for  the 
development  specification  function  for  both  the  prototype  and 
formal  kernel  development. 


Task  3.2  Prototype  Kernel  Development 

This  task  will  implement  and  test  the  prototype  security  kernel 
for  the  SFEP  in  assembly  language.  This  prototype  will  be 
integrated  with  Operating  System  software  developed  under  Task 
3.7  and  used  in  the  free-standing  SFEP  demonstration.  The 
free-standing  SFEP  will  be  used  for  evaluation  testing  of  the 
kernel.  The  prototype  will  serve  as  the  model  for  the  formal 
kernel  to  be  implemented  in  Task  3.3. 

The  prototype  kernel  implementation  will  be  based  on  the  formal 
specifications  developed  under  Task  3.1.  A detailed  design  will 
be  carried  out  and  documented  as  a preliminary  Product 
Specification.  Tnis  will  include  a description  of  tne  kernel 
structure  and  functions,  the  data  base,  the  individual  program 
modules  or  components,  and  a detailed  definition  of  the  interface 
between  the  kernel  and  operating  system/application  software. 

The  prototype  kernel  will  be  implemented  and  tested.  Test  cases 
will  oe  developed  to  check  out  the  kernel  and  to  allow  its  use  in 
the  free-standing  SFEP  demonstration.  After  the  demonstration, 
the  prototype  kernel  Product  Specification  will  be  finalized. 

The  standards  established  in  Task  3.6  will  be  followed  during  the 
development  of  the  prototype  kernel.  This  will  allow  the 
prototype  kernel  design  to  be  used  for  the  formal  kernel.  Some 
differences  between  the  formal  and  prototype  kernel  designs  are, 
of  course,  anticipated  as  a result  of  the  certification  and 
test/evaluation  activities. 


Task  3.3  Formal  Kernel  Development 

This  task  will  implement  the  SFEP  Kernel  in  the  system 
programming  language  defined  under  Task  3.6.  This  kernel  will  be 
integrated  with  other  SFEP  software  and  used  in  the  intermediate 
Multics  demonstration  that  integrates  Multics  and  the  SFEP. 

The  formal  kernel  will  be  based  on  the  specifications  developed 
under  Task  3.1  and  certified  under  Task  3.4.  It  is  expected  that 
both  the  certification  effort  and  the  prototype  kernel  testing 
will  identify  changes  that  must  be  made  to  the  specifications. 
These  cnanges  will  be  made  under  this  task,  the  certification 
will  be  updated  under  Task  3.4. 

After  this  update  is  completed,  the  detailed  design  for  the 
prototype  kernel  will  be  updated  to  reflect  the  revisions  and  to 
include  the  full  functionality  of  the  formal  specifications.  The 
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latter  includes  functions  such  as  the  Multics  kernel  interface. 
The  detailed  design  will  be  incorporated  into  a preliminary 
Product  Specification  for  the  formal  kernel.  This  specification 
will  be  submitted  to  the  Air  Force  for  review.  After  the  Air 
Force  review,  the  kernel  will  be  implemented  in  the  system 
programming  language,  compiled  (using  the  compiler  developed 
under  Tasks  1.1  and  3.5)  and  tested.  It  is  then  ready  for  use  in 
the  intermediate  Multics  demonstration.  Formal  kernel 
development  and  modification  will  be  performed  by  cleared 
personnel  within  a secure  environment  similar  to  that  in  which 
the  Multics  kernel  .development  similar  to  that  in  which  the 
Multics  kernel  development  will  take  place. 


Task  3.4  Certification  Procedure  Development 

This  . task  addresses  the  effort  required  for  technical 
certification  of  the  SFEP  kernel  software.  The  effort  is 
subdivided  into  four  main  activities:  1)  establishing  procedures 
and  tools  for  certification  and  maintenance  of  certification;  2) 
on-going  review  of  the  kernel  development  to  assure  that  the 
specifications  and  design  are  proceeding  in  a direction  that 
allows  certification,  3)  the  actual  technical  certification, 
(i.e.,  correspondence/correctness  proofs),  and  4)  the  maintenance 
of  these  proofs.  To  maximize  the  probability  of  success,  the 
SFEP  certification  effort  will  be  coordinated  with  the  Multics 
effort  and,  where  feasible,  commonality  with  Multics  techniques 
and  tools  will  be  maintained. 


The  procedures  and  tools  to  be  used  for  the  technical 

certification  and  maintenance  of  this  certification  will  be 

established.  It  is  expected  that  automated  tools  will  not  be 

used  for  the  certification  activity;  however,  some  might  be 
appropriate  for  the  maintenance  effort.  Procedures  and  tools 
established  for  Multics  will  be  reviewed  and  used  as  appropriate. 
The  chosen  approach  will  be  shown  to  be  sufficient,  will  be 

documented,  and  a plan  prepared  for  carrying  out  the 
cer  tif icat ion . 


The  certification  team  will  carry  out  an  on-going  review  of  the 
kernel  development  effort.  This  will  increase  the  probability  of 
success  in  the  certification  effort  by  minimizing  the  use  of 
inappropriate  techniques. 


The  actual  certification  will  be  carried  out  in  three  steps. 
First,  the  correspondence  proof  between  the  kernel  top  level 
specification  and  the  Air  Force  security  model  will  be  developed; 
next,  the  correspondence  between  intermediate  levels  of 
abstraction  will  be  proven;  and  finally,  (under  Task  1.27)  the 
proof  of  correctness  of  the  system  programming  language 
representation  will  be  attempted.  A similar  process  will  be 
carried  out  for  the  trusted  processes.  However,  it  is  expected 
that  the  certification  of  the  trusted  processes  will  require  less 
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effort  than  distributed  kernel  certification.  The  proofs  at  each 
step  will  be  documented  and  submitted  to  the. Air  Force  for 
review . 

The  correspondence  proofs  will  be  updated  if  major  changes  are 
made  to  the  specifications  or  programs. 

A final  technical  report  on  the  certification  effort  ' will  be 
prepared  at  the  end  of  the  project. 

Etocuments  and  software  used  in  the  certification  process  will  be 
safeguarded  consistent  with  configuration  management  procedures 
(Task  4.2). 


Task  3.5  Software  Development  Tools 

This  task  will  ensure  that  the  necessary  language  and  software 
development  tools  are  available  for  the  development  of  SFEP 
software.  Items  included  are:  assembler,  simulator,  system 
programming  language,  compiler,  loader  and  an  interactive  debug 
routine . 

Requirements  for  the  software  development  tools  are  based  on 
following  a two-step  approach.  Initial  development  of  SFEP 
software  will  be  done  on  a Multics  host  resident  system 
consisting  of  an  assembler,  simulator,  and  (for  the  formal 
kernel)  compiler.  This  will  allow  interactive  software 
development,  using  the  Multics  based  software  for  source  edits, 
file  maintenance,  assemblies  and  debug  and  check-out  via  the 
simulator.  Use  of  the  host  resident  software  will  also  minimize 
schedule  conflicts  for  the  use  of  SFEP  development  hardware. 
Without  the  host  resident  software,  multiple  software  developers 
would  be  co.mpeting  with  each  other  and  the  hardware  testing  and 
evaluation  activity  for  use  of  the  SFEP  hardware.  Final  software 
checkout  must,  of  course,  be  done  on  the  actual  SFEP  hardware. 
Thus,  som.e  native  mode  software  will  also  be  required.  This 
latter  will  be  based  on  existing  minicomputer  software  modified 
to  accommodate  the  SPM.  The  software  development  items  are 
discussed  in  the  following  paragraphs. 

Assembler  - The  existing  Multics  resident  assembler  will  be 
modifFed  to  handle  the  added  functions  of  the  SPM.  The  existing 
assembly  language  manuals  will  be  updated  to  reflect  these 

changes.  This  assem.bler  will  be  used  in  development  of  the 
prototype  kernel,  the  operating  system  and  the  communications 

subsystem . 

Simulator  - The  existing  Multics  resident  interpretive  simulator 
for  the  selected  minicomputer  will  be  modified  to  include  the  SPM 
functions.  A user's  manual  will  be  prepared.  The  simulator  is 
required  to  allow;  SFEP  hardware  evaluation  prior  to 
availability  of  the  actual  hardware,  development  of  SFEP  hardware 
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test  and  verification  software,  analysis  of  probabilistic  measure 
of  security  compromise  (Task  2.6),  and  Multics  host  resident  SFEP 
software  development  as  described  above. 


System  Programming  Language  ^_d 
certifiability  ^ the  "SFEP  ker 
be  used  as  an  intermediate  step 
intended  that  a common  language 
kernels.  The  degree  of  commonal 
task  through  review  of  the 
modified  PL/I)  under  Task  1.1. 
possible  because  of  hardware 
necessary  changes  to  the  Multics 
this  task. 


Compiler  - To  allow 

nei,'a  higher  level  language  must 
in  the  kernel  development.  It  is 
be  used  for  the  SFEP  and  Multics 
ity  will  be  determined  under  this 
language  defined  for  Multics  (a 
If  a 100%  commonality  is  not 
architecture  differences,  the 
language  will  be  defined  under 


A compiler  will  be  developed  to  translate  this  language  into  the 
SFEP  assembly  language.  Under  this  task,  a code  generator  for 
the  SFEP  will  be  developed  and  integrated  with  the  front-end 
(syntax  analyzer)  of  the  compiler  developed  under  Task  1.1. 


Loader  ar^  Cebug  - The  existing  minicomputer  loader  and 
Interactive  debug  programs  will  be  modified  to  work  with  the 
SFEP.'  User  documentation  will  be  updated. 


Task  3.6  Formal  Programming  Technology 

This  task  will  establish  standards  and  ensure  that  they  are 
followed  throughout  the  course  of  the  project. 

To  assure  that  SFEP  kernel  software  certification  can  be 
accomplished,  standards  will  be  established  and  documented  for 
formal  specifications  and  programming  conventions.  Standards 
established  for  Multics  will  be  reviewed  and  used  as  appropriate. 
Necessary  training  to  familiarize  personnel  with  these  standards 
will  be  carried  out. 


Task  3.7  Develop  OS  Functions  for  Multics  SFEP 

This  tasK  will  develop  the  supervisor  and  service  functions  that 
are  required,  in  addition  to  the  communications  subsystem  and 
kernel,  to  develop  and  demonstrate  the  Multics  SFEP. 


The  supervisor  functions  consist  of  the  resource  allocation 
"policy"  functions  that  do  not  impact  security.  While  the 
specifics  of  functionality  and  implementation  remain  to  be 
defined,  two  basic  functions  are  planned.  These  are  a process 
scheduler  and  a memory  manager.  The  scheduling  function  will 
establish  process  priority  and  communicate  its  scheduling 
decisions  to  the  kernel.  The  memory  manager's  primary  functions 
will  be  the  housekeeping  of  free  memory  and  buffers.  The  actual 
dispatching  and  allocation  of  physical . resources  will  be  done  by 
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the  kernel.  The  classification  of'  some  of  these  supervisor 
functions  as  system  high  routines  will  be  done  as  part  of  this 
task.  Three  other  functions  normally  in  a supervisor  (clock, 
interrupt  and  trap  management) , are  to  be  handled  by  the  kernel. 

Other  functions  to  be  implemented  under  this  task  include:  an 
operator  interface,  input/output  device  drivers,  and  a bootload 
function . 

These  functions  are  included  primarily  to  support  integration  and 
test  activity.  However,  they  are  all  consistent  with  the 
"general  purpose"  SFEP  objectives.  The  peripheral  devices 
include:  a disk  (to  support  software  development  and  test),  a 
diskette  (for  bootloading),  and  an  operator/raaintenance  console 
(for  troubleshooting).  The  bootload  function  is  required  for 
free-standing  operation  and  for  troubleshooting.  Specific 
functionality  and  implementation  details  of  these  functions  will 
be  defined  as  part  of  the  design  task. 

Two  important  omissions  should  be  noted.  First,  the  SFEP  will 
not  support  peripherals  for  Multics.  Second,  automatic  recovery 
from  failures  is  not  addressed.  The  recovery  problem  is  assumed 
to  be  outside  the  scope  of  this  effort. 

The  design  of  the  OS  functions  will  be  based  on  constraints 
imposed  by  the  kernel  formal  specifications  and  on  tne  kernel  to 
OS  interface  specified  by  the  prototype  kernel  design  in  Task 
3.2.  Based  on  these  constraints,  a development  specification 
will  be  prepared  for  the  OS.  Detailed  design  will  be  carried  out 
and  implemented  in  assembly  language.  A product  specification 
for  the  OS  will  be  prepared. 


Task  3.8  Develop  SFEP  Communications  Subsystem 

This  task  will  develop  tne  communications  subsystem  for  the 
Multics  SFEP.  Two  basic  functions  will  be  included.  These  are  a 
terminal  handler  and  a Multics/SFEP  interface.  Some  elements  of 
these  functions  will  be  trusted  processes. 

The  communications  subsystem  design  requirements  will  be  based  on 
many  constraints.  These  include:  kernel  formal  specifications, 
detailed  kernel  design,  agreed-to  Multics/SFEP  interface 
protocol,  detailed  operating  system  design,  and  Multics  terminal 
and  network  interfaces.  The  definition  of  functional  and 
interface  requirements  will  be  coordinated  with  both  the  Multics 
design  team  and  the  Air  Force. 
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Task  3.9  SFEP  Integration  and  Test 

This  task  will  unite  the  SFEP  hardware  and  software  into  a single 
system,  integrate  it  with  a Multics  host,  and  demonstrate  that  it 
'can  perform  the  Multics  front-end  processing  functions.  This 
will  be  accomplished  in  three  steps:  progressing  from  a 
free-standing  SFEP  system,  through  an  intermediate  Multics/SFEP 
system,  to  the  prototype  Multics/SFEP  system. 


The  free-standing  SFEP  system  will  demonstrate  the  operation  of 
SCOMP  hardware  and  kernel  software.  This  system  will  be 
established  by  integrating  the  SCOMP  hardware  from  Task  2.0  with 
the  following  SFEP  software  elements:  prototype  kernel  from  Task 
3.2  and  operating  system  software  from  Task  3.7.  The 
free-standing  system  will  also  be  used  for  performance 
evaluation. 


The  intermediate  Multics/SFEP  system  will  demonstrate  the  ability 
of  the  SFEP  to  interface  with  Multics  and  perform  its  front-end 
functions.  For  this  demonstration,  the  formal  kernel  (still 
uncertified  at  this  point  in  time)  from  Task  3.3  will  be  used. 
The  communications  subsystem  software  from  Task  3.7  will  be  used 
to  handle  the  Multics  interface  and  the  terminal  subsystem. 


The  final  demonstration  will  incorporate  the 
changes  made  to  the  software  as  a result 
demonstrations  and  the  certifications  activity. 
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the  resource 


r equ i rements 


necessary 


53 


MANPOWER  PROJECT  GUARDIAN 

MANMONTIIS/QUARTERS  TASK  3.0  SECURE  FROrrT  END  PROCESSOR  - SOFTWARE 


I 


"'T 

fn 

o 

c 

— 

o * 

fN 

r> 

r> 

m 

O 

6 

o 

VO 

r> 

vO 

O 

O 

o 

TT 

vO 

r> 

vO 

— 

r> 

r> 

O' 

r> 

— 

vn 

r* 

9 

* 

(Ti 

tN 

fO 

m 

00 

•H 

o 

O 

vn 

vO 

r> 

r» 

o 

O 

in 

O 

O 

VO 

m 

00 

vO 

o 

o 

vn 

o 

vn 

00 

m 

m 

m 

TT 

VO 

CO 

r* 

(Ti 

rS 

o 

in 

o 

m 

CM 

m 

VO 

00 

o 

vn 

o 

o 

m 

VO 

VO 

o 

C 

o 

m 

o 

O 

VO 

m 

r> 

00 

CM 

- — — 1 

o 

O 

O 

vn 

o 

m 

O' 

r> 

m 

r* 

VO 

r* 

r* 

o 

O 

vn 

vn 

vn 

o 

O' 

(N 

• 

• 

9 

9 

O' 

m 

o 

VO 

— 

"~D“ 

“rr 

— 

““O — 

Tn*“ 

~in  “ 

~u\~ 

"D" 

\D 

VO 

m 

r* 

o 

vO 

•H 

O 

o 

o 

m 

vn 

vn 

\o 

vO 

r* 

CO 

vn 

o 

\D 

I-H 

r* 

O' 

O 

o 

o 

vn 

vn 

vn 

1 

m 

\o 

m 

VO 

o 

o 

rH 

t 

s 

u 

fc: 

< 

s 

CLi 

£ 

u 

o 

■iJ 

(fa 

JJ 

c 

CO 

CO 

>H 

1 

CO 

CO 

0* 

0 

A 

c 

0 

-»H 

a 

0 

4J 

CO 

4J 

0) 

O' 

4J 

c 

> 

0 

cn 

to 

£ 

c 

o 

£ 

4J 

a 

I-H 

0 

0 

4J 

a 

0 

c 

w 

to 

Uh 

0 

% 

0) 

0 

J= 

0 

4J 

a 

i 

u 

E-* 

u 

Uh 

<0 

u 

0 

D 

Q 

U 

0) 

> 

0 

*0 

4J 

E- 

cn 

*0 

a 

i? 

0) 

c 

c 

c 

c 

CO 

Q 

0) 

CJ 

$ 

O' 

0 

a 

<0 

> 

0 

£ 

c 

E 

a 

u 

•H 

4J 

£ 

c 

0) 

0) 

Q 

0« 

0 

g 

u 

0 

0 

c 

c 

I-H 

£ 

c 

U 

u 

u 

•-H 

c 

0) 

« 

3 

4J 

o 

o 

0) 

0 

> 

W 

(fa 

(X 

<0 

z 

Ui 

c 

D> 

Ui 

w 

o 

u 

4J 

Q 

0 

CO 

Cfa 

C7' 

IH 

o 

o 

U 

o 

CO 

0) 

E- 

Cl 

a 

0 

0) 

a 

U 

C* 

> 

>. 

u 

a 

a 

c 

M 

IM 

n 

0 

0 

M 

(X 

0 

<CJ 

u 

1 

4J 

g 

4J 

4J 

£ 

Cl 

o 

a 

0 

w 

Uh 

Wt 

> 

> 

bi 

u 

p 

u 

0 

0) 

0 

0 

Q 

iP 

(fa 

Q 

E^ 

a 

(fa 

u 

CO 

(fa 

Q 

a 

CO 

« 

w 

i-H 

fV» 

r> 

»n 

VO 

r- 

CO 

O' 

E- 

m 

m 

m 

fO 

m 

m 

r> 

m 

n 

54 


i 


Section  IV 


Project  Control 


In  trod  uc  tion 

This  task  is  the  central  focal  point  for  control  and  support  of 
all  technical  and  management  activities  in  the  project.  Through 
management  support,  this  task  initiates  all  technical  and 
management  review  activities  for  all  aspects  of  the  project.  All 
project  documentation  is  also  centralized  and  coordinated  by  this 
task.  To  support  all  system  development  requirements,  the  Project 
Control  task  also  has  responsibility  for  providing  computer 
system  resources  on  a regular  basis. 

Tnis  task  will  provide  continuous  and  efficient  support  to  all 
project  activities.  Any  identified  problems  anywhere  in  the 
project  will  oe  resolved  by  personnel  assigned  to  this  task.  To 
achieve  a smooth,  efficient  project,  this  task  will  provide  a 
coordinated  flow  of  all  project  documentation  to  the  Air  Force. 

A Multics  service  system  will  provide  tne  administrative  tools  of 
document  preparation,  editing,  program  schedule  maintenance,  and 
other  administrative  efforts.  When  mutually  agreeable,  all 
published,  unclassified  documents  produced  oy  this  project  can  be 
printed  at  any  time  as  they  will  be  available  for  common  perusal 
by  appropriate  Air  Force  and  Honeywell  personnel.  In  this  way, 
automated  project  control  procedures  will  be  an  integral  part  of 
this  program. 


Task  4.1  Project  Management 

This  tasK  will  integrate  all  efforts  of  the  contractor  and 
subcontractor  organizations.  The  Project  Management  task  will 
coordinate  the  intermediate  , technical  milestones  which  are 
required  to  support  project  decision  points  for  the  Air  Force. 
Specific  subtasks  are: 

a.  Preparation  and  update  of  a continuous  program  schedule 
for  Air  Force  review 

b.  Preparation  and  scheduling  of  formal  Technical  Review 
meetings . 

In  addition  to  the  technical  review  meetings,  Project  Management 
will  conduct  regular  montnly  management  review  meetings  and,  as 
they  become  necessary,  informal  technical  working  meetings. 

Project  Management  will  ensure  that  program  objectives  are 
accomplished  in  a timely  and  cost-effective  manner.  This  task 
impacts  all  aspects  of  the  project  and  includes  the  following 
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subtasks : 


a.  cost  control 

b.  schedule  control 

c.  status  report  control 

Task  4.2  Configuration  Management 

This  task  establishes  procedures  and  controls  for  configuration 
management  and  coordinates  all  changes  to  authenticated 
configurations.  Configuration  control  will  be  the  formal  means 
of  ensuring  the  integrity  of  the  system  and  success  of  the 
project.  A plan  will  be  produced  that  defines  policies  and 
procedures  for  configuration  control. 

The  configuration  management  task  will  provide  configuration 
control  over  the  followina  items: 


a • 

Prototype  Secure  Multics 

b. 

Security  Protection  Module  (allocated) 

c . 

Honeywell  6000/Series  60  Interface  Unit 

d . 

Multics  lOM  Modifications 

e . 

Multics  Security  Kernel 

f . 

SFEP  Security  Kernel 

Ta  s k 4 . 

,3  Data  Management/Documentation 

This  task  provides  all  the  data  management  (i.e.,  documentation) 
to  coordinate  and  monitor  the  progress  of  preparation,  review  and 
distribution  of  project  documentation.  Outputs  from  this  task 


are  as 

follows : 

a . 

, Technical  Status  Reports 

b. 

, Technical  Specifications 

c . 

, Technical  Notes 

Task  4. 

.4  Computer  Resources  - Multics  Service  Site 

The  Multics  service  site  provides  the  initial  working  host  system 
on  wnich  program  development  and  unit  (isolated)  check-out  of 
software  wiil  occur.  The  Multics  service  system  is  a nonsecure 
site  and  provides  library  copies  of  all  current  system  software 
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and  project  documentation.  Initial  design  and  coding  of  system 
software  is  performed  on  the  service  system.  After  the  software 
is  developed  and  meets  the  designer's  satisfaction  as  to  unit 
checkout,  it  is  then  ready  for  trial  integration  on  the  Multics 
development  computer. 

The  nonsecure  Multics  service  site  will  be  MIT's  Information 
Processing  Center  in  Cambridge,  Massachusetts  with  supplemental 
service  provided  oy  Honeywell's  Multics  facility  in  Phoenix, 
Ar i zona . 

Use  of  the  Multics  service  system  is  in  a shared  nondedicated 
environment.  There  may  be  many  other  simultaneous  users  of  the 
service  system,  some  of  which  may  not  be  utilizing  the  system  for 
efforts  related  to  this  project. 


Task  4.5  Computer  Resources  - Multics  Development  Sites 

The  Multics  development  sites  provide  computing  facilities  in 
which  software  development  and  system  test  can  be  undertaken. 
There  are  two  different  development  sites  presently  identified 
and  required  for  this  project.  These  are  the  nonsecure  Multics 
development  system  at  Honeywell's  Cambridge  Information  Systems 
Laboratory  and  the  secure  development  site  at  Hanscom  Air  Force 
Base,  Bedford,  Massachusetts.  The  secure  development,  site  will 
be  established  specifically  for  the  purpose  of  supporting  system 
development  efforts  in  a cleared  facility. 


Task  4.5.1  Computer  Resources  - Nonsecure  Development  Site 

The  nonsecure  Multics  development  system  at  Honeywell's  Cambridge 
Information  System  Laboratory,  Cambridge,  Massachusetts,  will  be 
used  for  software  cneck-out  in  an  integrated  system  test  mode  in 
an  uncleared  facility.  Unlike  the  service  system,  the  nonsecure 
development  system  is  used  in  a dedicated,  block-time 
environment.  Normally,  users  other  than  the  designer  responsible 
for  the  specific  integration/system  test  run  are  not  permitted 
simultaneous  access  to  the  development  system.  Each  computer  run 
IS  identified  by  a sign-up  sheet  for  a block  of  time. 

Due  to  the  very  nature  of  block-time  usage,  the  Multics  service 
site  cannot  be  the  same  as  the  Multics  development  site.  The 
service  system  provides  regular  continuous  service  and  extreme 
scheduling  difficulties  arise  in  trying  to  intermix  development 
block-time  requirements  with  continuous  undisrupted  service 
requirements . 


Task  4.5.2  Secure  Development  Site 
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Prior  to  the  recoding  of  the  Multics  and  SFEP  security  kernels, 
the  secure  Multics  development  system  must  be  established.  This 
secure  site  is  required  so  that  the  kernel  development  for  the 
operational  prototype  secure  Multics  demonstration  and  the  final 
SFEP  can  be  performed  in  a Top  Secret  controlled  location  to 
maintain  integrity  of  the  security  kernels.  The  secure  Multics 
development  system  will  be  installed  in  government-furnished 
facilities.  The  establishment  of  this  site  requires 
specially-trained  site  support  and  operations  personnel.  Task 
1.30  has  defined  the  preparation  of  the  secure  site.  Task  1.29 
has  described  the  task  of  developing  a team  of  systems  designers 
who  will  perform  the  software  development  of  the  security  kernels 
for  the  operational  prototype  secure  Multics  demonstration  and 
the  final  SFEP  in  the  secure  development  site.  These  system 
designers  are  separate  and  distinct  from  the  site  and  operations 
support  personnel  required  to  maintain  continuous  operation  of 
the  secure  development  site. 

The  secure  development  site  is  an  interim  facility  for  integrated 
system  test,  and  preliminary  test  and  evaluation,  of  hardware  and 
software  components,  prior  to  the  eventual  installation  of  the 
secure  Multics  at  an  operational  site  such  as  the  Air  Force  Data 
Services  Center  (AFDSC) . The  installation  of  the  secure  Multics 
at  this  operational  site  is  a major  goal  of  this  Integration  Plan 
but  has  not  been  included  in  the  resource  estimates  provided, 
because  the  actual  installation  will  occur  after  the  five-year 
scope  of  this  plan. 


Task  4.6  SFEP  Resources 

Paralleling  the  Multics  development  sites  is  the  nonsecure  SFEP 
development  site  at  Honeywell's  Aerospace  facility.  This  site 
will  provide  all  computer  resources  necessary  for  the  development 
of  the  SFEP  software.  The  nonsecure  SFEP  system  will  be  used  for 
both  the  unit  check-out  and  integrated  check-out  of  all  SFEP 
software.  A second  SFEP  system  will  be  installed  in  the  secure 
Multics  development  site  described  in  Task  4.5.2  above  to  support 
the  operational  prototype  Multics  demonstration. 


Resource  Requirements 


The  following  table  indicates 
for  the  subtasks  of  Task  4.0. 


the  resource  requirements  necessary 
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MANPOWER  PROJECT  GUARDIAN 

MANMONTHS /QUARTERS  TASK  4.0  PROJECT  COrrTROL 
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Section  V 


SumiTiary  and  Conclusions 


This  report  describes  the  problenn  of  multilevel  computer 
security,  reviews  past  efforts  in  the  field.  The  earlier 
programs  have  carried  the  reference  monitor  concept  from  an 
academic  abstraction  to  a limited  security  kernel.  An  Integrated 
plan  has  been  presented  in  this  report  to  carry  the  security 
kernel  concept  into  a large-scale  computer  system.  The  plan  is 
composed  of  three  major  development  tasks  and  one  support  task. 
The  eventual  goal  of  these  tasks  is  to  demonstrate  the 
feasibility  of  attaining  a certifiably  secure  Multics  service. 
This  program  will  attain  the  goal  of  an  open,  multilevel,  secure 
computer  system. 

Task  1.0  is  the  mainline  task  of  the  project.  It  integrates  the 
results  of  the  other  tasks  and  provides  the  catalyst  to  attain 
the  program  goal.  The  end  result  of  Task  1.0  will  be  a 
demonstration  that  the  program  goals  have  been  met.  Other 
benefits  are  a greatly  increased  understanding  of  the  problem  of 
computer  security  and  a well-developed  methodology  for  specifying 
future  secure  computer  systems. 

Tasks  2.0  and  3.0  support  Task  1.0,  supplying  the  required 
communications  capability.  The  end  result  of  these  tasks  will  be 
a certifiable  secure  communications  front-end  processor  for  use 
with  Multics.  Other  benefits  are  increased  understanding  of  the 
problem  of  communications  processor  security  and  a well  developed 
methodology  for  specifying  future  secure  communications 
processors . 

Task  4.0  supports  the  other  three  tasks.  The  primary  function  of 
Task  4.0  is  to  ensure  the  coordinated  management  of  the  program. 
The  principle  long  term  benefit  is  an  integrated  collection  of 
program  documentation. 

The  resulting  prototype  Multics  computer  system  will  demonstrate 
the  ability  of  the  military  to  process  information  of  mixed 
security  levels.  This  will  be  a major  step  toward  the  military's 
capability  to  make  secure  multilevel  on-line  systems  operational 
and  should  result  in  the  saving  of  a large  portion  of  tne  annual 
cost  of  computation.  Other  agencies  will  benefit  also,  as  the 
availability  of  secure  computer  systems  will  increase  their 
ability  to  build  data  processing  systems  that  truly  safeguard 
information  and  help  to  ensure  the  individual's  rights  to 
pr ivacy . 
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Suimnary  of  Resource  Requirements 


The  following  table  summarizes 
necessary  to  perform  all  the  tasks 


the  resource 
described  in  this 


requirements 

report. 
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TOTAL  RESOURCE  REQUIREMENTS 
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Appendix  A 
Supporting  Efforts 


Introduction 

Earlier  sections  of  this  report  have  identified  and  described  tne 
four  major  tasks  involved  in  the  design  and  development  of  a 
secure  Multics.  This  Appendix  identifies  and  describes  a set  of 
supporting  efforts  that  may  be  followed  in  order  to  augment  the 
secure  Multics  and  to  extend  its  utility.  These  supporting 
efforts  are  in  addition  to  those  required  for  the  major  tasks 
described  in  the  main  sections  of  this  Integration  Plan.  They 
cover  desirable  capabilities,  but  are  not  essential  to  meet  the 
principle  goals  of  Project  Guardian. 

tour  supporting  efforts  nave  been  identified  at  this  time.  It  is 
expected  that  additional  efforts  will  be  defined  as  the  project 
proceeds.  The  supporting  efforts  described  below  are: 

A.  Secure  Data  Base  Management  System 

B.  Cryptographic  Multiplexor 

C.  Secure  Office  Terminal 

D.  Security  Audit  and  Surveillance 

Each  is  described  in  a separate  section  below. 
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Supporting  Effort  A:  Secure  Data  Base  Management  System 


Section  Al.O  INTRODUCTION  AND  OVERVIEW 


This  supporting  effort  addresses  the  design,  development, 
implementation,  and  possible  certification  of  a Data  Base 
Management  System  (DBMS)  which,  when  operating  on  the  secure 
Multics,  would  provide  the  capability  for  a data  base  to  contain 
data  of  several  classification  levels  and  categories  and  be 
accessible  by  users  of  various  clearance  levels  and  categories 
while  guaranteeing  that  no  unauthorized  data  accesses  can  occur. 

There  are  several  possible  approaches  to  the  solution  of  this 
problem,  namely: 

(1)  The  design  proposed  by  Hinke  and  Schaefer,  of  System 
Development  Corporation  (SDC) ; (1) 


(2)  An  extension  of  the  Multics  Data  Base  Manager  (MDBM) 
currently  under  development  by  Honeywell,  the  initial 

version  of  which  is  to  be  included  in  MR  4.0.  Such  an 
extension  would  oe  necessary  in  order  to  provide  multilevel 
access  control  at  the  attribute  (field)  level.  Currently, 
the  MDBM  provides  access  control  only  at  the  relation 
(record  type)  level.  There  are  two  such  extensions 

currently  under  consideration.  One  approach  would  require 
that  the  MDBM  contain  security  sensitive  code,  but  may 
provide  superior  performance, 
require  security  sensitive  code, 
degraded  performance;  although 
be  as  severe  as  would  be  expected 


Another  approach  may  not 
but  may  also  result  in 
the  degradation  should  not 
for  tne  SDC  proposal. 


The  basic  difference  among  all  approaches  concerns  the  data  base 
storage  format  and  the  resulting  effects  upon  performance, 
compatabil i ty  with  the  standard  product,  and  the  possibility  of 
the  existence  of  security  sensitive  code  within  the  DBMS. 


It  is  therefore  proposed  tnat  this  task  commence  with  a study  to 
evaluate  the  relative  merits  of  these  approaches  and  to  choose 
from  among  them.  If  the  SDC  proposal  is  chosen,  the  study  would 
be  followed  by  tasks  to  design  and  implement  the  proposed 
primitive  functions  and  to  incorporate  them  into  the  MDBM.  If  an 
Honeywell  approach  is  chosen,  the  following  tasks  would  be  to 
design  the  specified  security  modifications  and  incorporate  them 
into  the  MDBM.  If  it  is  necessary  for  security  sensitive  code  to 
exist  within  the  MDBM,  then  the  programming  language  and 


( I)  Thomas  H . HThTce  ana  ^Tarvfn“ScH¥efe'^7~"'bec'u  Data  Tlan^gemeht' 
System",  RADC-TR-75-266 , System  Development  Corporation,  Santa 
Monica  CA,  November  1975. 
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methodology  developed  in  major  Tasks  1.1,  1.5,  and  3.4  would  be 
utilized  to  re-implement  and  prove  the  correctness  of  the 
security  sensitive  code.  The  task  schedules  show  an  estimate  of 
the  manpower  required  to  perform  the  effort  for  both  approaches. 


Section  A2.0  TASK  FLAN 


Task  A1 . 0 Study  to  Evaluate  Alternatives 

The  goal  of  this  task  is  to  choose  between  the  data  base 
structure  proposed  by  SDC  and  that  defined  for  the  MDBM. 
Both  are  relational  structures,  but  differ  in  that  the  SDC 
proposal  requires  that  relation  attr ibutes  be  stored  in 
separate  files,  while  the  MDBM  places  an^^ntir’e  relation  in 
a file.  One  result  of  this  difference  Ts  that  the  SDC 
approach  may  cause  a significant  performance  degradation 
because  of  the  larger  number  of  segments  required  to  be 
active  while  accessing  the  data  base.  However,  tnere  is  a 
possibility  that  the  inclusion  of  security  sensitive  code 
may  be  required  within  the  MDBN,  in  order  to  provide 
multilevel  security  at  the  attribute  (field)  level. 

The  following  tasks  will  be  performed  during  this  study: 

(1)  A comparison  between  the  performance  of  the  MDBN  and 

that  of  an  attr ibu te-per-segment  relational 

implementation  will  be  performed.  One  approach  may  be 
to  use  an  existing  attribute-per-segment  implementation 
such  as  tne  Relational  Data  Management  System  (ROMS)  at 
MIT.  Another  approach  may  be  to  perform,  a rudimentary 
implementation  of  the  SDC  proposed  primitives. 

(2)  A determination  of  tne  amount  of  security  sensitive 

code  within  the  MDBM  required  to  provide  multilevel 

security  at  the  attribute  (field)  level  will  be  made 
for  all  Honeywell  approaches.  There  is  a high 

probability  that,  in  one  approach,  none  would  be 
required. 

(3)  An  evaluation  of  the  impacts  of  all  approaches  with 
regard  to  standard  product  compatabii ity  will  be 
performed . 

(4)  Based  on  the  results  of  the  above  tasks,  a decision 

will  be  made  as  to  which  approach  the  actual 

im, piemen tation  is  to  follow.  A final  technical  report 
containing  the  rationale  for  the  decision,  together 
with  specifications  for  the  design  and  implementation 
of  the  chosen  approach,  will  be  produced.  This  report 
will  be  the  subject  of  a design  review  at  the 
completion  of  this  task. 
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At  this  point  in  the  task,  one  of  two  paths  will  be  followed, 
depending  upon  the  decision  resulting  from  Task  Al.O. 

Task  A2.0  SDC  Approach 

The  following  three  subtasks  are  required  if  the  SDC  approach  is 
chosen. 


Task  A2.1:  Design  of  the  SDC  Proposed  Primitives 

This  task  will  involve  the  design  of  those  primitives 
defined  'in  the  SDC  report,  and  identification  of  the  points 
of  interface  with  the  MDBM.  The  output  from  this  task  will 
be  a design  document.  Further  work  will  be  contingent  upon 
the  approval  of  the  design  at  a design  review  to  be  held  at 
the  time  this  task  is  completed. 

Work  will  proceed  concurrently  along  two  fronts: 

(1)  the  design  of  the  data  manipulation  and  data 
description  primitives  specified  in  the  SDC  proposal. 

(2)  the  identification  and  specification  of  the  interfaces 
between  the  primitives  and  the  MDBM.  Tnis  will  'involve 
all  points  where  the  MDBM  is  to  communicate  with  the 
database,  the  data  descriptions,  and  the  storage 
str uc  tur e . 


Task  A2.2:  Implementation  of  the  Primitives 

This  task  will  begin  after  successful  completion  of  the 
above  design  review.  It  will  involve  the  development  of  a 
Multics  space  manager  conforming  to  the  suggestions  in  the 
SDC  report.  The  result  will  be  a set  of  primitives  coded  in 
PL/I  whicn  will  be  utilized  by  all  data  description  and  data 
manipulation  functions  of  the  MDBM. 

Work  will  proceed  concurrently  along  two  paths: 

(1)  the  development  of  the  data  manipulation  primitives  as 
described  in  section  4.3.1  of  the  SDC  report. 

(2)  the  development  of  the  data  description  primitives 
mentioned  in  section  4.3.2  of  the  SDC  report. 


Task  A2.3:  Incorporation  of  the  Primitives  Into  the  MDBM 

This  task  will  involve  the  incorporation  into  the  MDBM  of 
all  the  primitives  developed  in  the  previous  task.  This 
task  includes  testing  and  performance  tuning.  Those 
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portions  of  the  MDBM  identified  in  Task  A2.1  will  be 
rewritten  to  accomodate  the  primitives  and  the  proposed 
storage  structure.  The  output  of  this  task  will  be  a 
demonstrable  version  of  the  MDBM  which  uses  the  primitives 
for  all  data  description  and  data  manipulation  functions. 


At  this  point,  Task  A is  completed  if  the  SDC  approach  was 
followed . 


Task  A3.0  Honeywell  Approach 

The  following  describes  the  subtasks  required  if  one  of  the 
Honeywell  approaches  is  followed. 


Task  A3.1:  Design  of  the  MDBM  Security  Modifications 

The  modifications  to  the  MDBM  necessary  to  implement  a 
multilevel  security  capability  will  be  designed  in 
accordance  with  the  specifications  produced  by  Task  Al.O. 
The  output  of  this  task  will  be  a technical  design  memo. 


Task  A3. 2:  Implementation  of  the  MDBM  Security  Modifications 

The  MDBM  security  modifications,  as  designed  in  the  previous 
task,  will  be  implemented.  This  task  includes  testing  and 
performance  tuning.  Tney  will  oe  coded  in  PL/I.  The  output 
of  tnis  task  will  be  a demonstrable  version  of  the  MDBM 
whicn  incorporates  the  security  modifications.  If  the 
security  modifications  do  not  require  the  use  of  security 
sensitive  code  witnin  the  MDBM,  this  will  be  the  final 
pr oduc  t . 


The  following  subtasks  are  required  only  if  an  Honeywell  approach 
requiring  security  sensitive  code  within  the  MDBM  has  been 
cnosen . 


Task  A3. 3:  Reimplementation  of  MDBM  Security  Sensitive  Code 

If  the  security  modifications  require  the  use  of  security 
sensitive  code  within  the  MDBM,  this  code  will  be 
reimplemented,  using  the  System  Programming  Language 
developed  as  part  of  major  TasK  1.1,  for  inclusion  as  part 
of  the  third  Multics  prototype. 
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Task  A3. 4:  Proof  of  MDBM  Security  Sensitive  Code 

If  the  security  modifications  require  the  use  of  security 
sensitive  code  within  the  MDBM,  the  techniques  developed 
under  major  Tasks  1.5  and  3.4  will  be  used  to  begin  the 
proof  of  this  code.  The  magnitude  of  this  task  will  be 
dependent  upon  the  then-current  state  of  the  art  of  program 
correctness  proofs.  A review  of  the  progress  of  this  task 
will.be  held  about  three  months  after  its  start. 
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MANPOWER  PROJECT  GUARDIAN 

MANMONTHS/QUARTERS  SECURE  DATA  BASE  MANAGEMENT  SYSTEM 
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Supporting  Effort  B:  Cryptographic  Multiplexor 


Section  Bl.O  INTRODUCTION  AND  OVERVIEW 

Tnis  supporting  effort  considers  and  plans  for  the  interface 
between  the  Secure  Communications  Controller  (SCC)  and  the  Secure 
Front-End  Processor  (SFEP).  The  Secure  Communications  Controller 
is  being  developed  under  the  sponsorship  of  the  Communications 
Security  Engineering  Office  (ESD/bcW).  (1)  The  SCC  integrated 
con-troller  and  communications  security  (cryptographic)  functions. 
The  SCC  will  be  capable  of  simultaneously  servicing  several 
remote  terminals  and  will  eliminate  the  need  for  one 
communications  security  (cryptographic)  device  at  the  computer 
site  for  each  remote  site.  The  SCC  may  be  considered  as  a 
cryptographic  multiplexor. 

The  planned  activities  for  accomplishing  tne  interface  are 
delineated  in  the  task  plan  of  Section  B2.0.  The  overall  goal  of 
the  plan  is  to  develop  a prototype  unit,  based  on  in-depth 
studies,  which  will  establish  a design  capable  of  an  easy 
transition  into  a production  phase.  Although  the  main  thrust  of 
tne  plan  is  an  optimized  prototype  unit,  a low-cost  parallel 
effort  (described  in  the  plan)  may  be  required  to  support  the 
study  activities.  The  task  schedule  shows  an  estimate  of 
manpower  requirements  to  accomplish  the  study  and  development  of 
the  proposed  SFEP/SCC  interface. 


Section  B2.0  TASK  FLAN 


Task  d1  SFEP/SCC  Interface  Integration  Studies 

This  task  shall  consist  of  defining  functionalities  and 
requirements  of  both  the  SFEP  and  SCC  from  the  standpoint  of 
supporting  multiple  secured  terminal  devices  through 
communication  links.  Tne  output  of  tnis  task  shall  result  in 
sufficient  understanding  and  definition  of  requirements  to 
implement  an  optimum  configuration  study  task  (Task  B5)  and  to 
decide  if  the  development  of  a functional  evaluation  unit  (Task 
B3)  would  be  advantageous  as  a vehicle  to  support  the  optimum 
study  task.  The  implementation  of  the  evaluation  unit  tasks 
shall  be  contingent  upon  the  results  of  these  initial  studies  and 
upon  Air  Force  approval. 


(Ij  'Secure  Commuri  feat  Tons  Controller",  Project  7820/01/01.' 
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Task  B2  Definition  of  a SFEP/SCC  Functional  Evaluation  Unit 


This  task  shall  define  the  degree  of  functionality  of  the 
Functional  Evaluation  Unit.  Available  hardware  elements  and 
hardware  design  tasks  shall  be  determined  according  to  the 
functionality  requirements.  Strong  consideration  shall  be  given 
to  incorporation  of  off-the-shelf  or  GFE  hardware  elements  to 
achieve  a low-cost  implementation.  In  addition  to  hardware 
selection,  test  and  evaluation  (T&E)  software  approaches  and 
techniques  shall  be  established. 

The  present  visibility  of  a functional  unit  indicates  its 
implementation  may  be  accom.pl ished  by  utilization  of  a prototype 
SFEP  with  a Multi  Line  Communication  Controller  (MLCC)  module 
containing  a Communication  Line  Adapter  (CLA) . 


The  SFEP/MLCC/CLA  to 
interface  would  probably 
unit.  The  interface  u 
as  ID  code  detection  and 
special  interface  requ 
the  units.  One  line,  of 
support  communications 
portion  of  the  functions 
telephone  communication 
terminal  (TTY  40  contain 
controller  module) . 


see  '(conceptual  demonstration  model) 
require  a specially  engineered  interface 
nit  is  expected  to  perform  functions  such 
answer  back,  data  formatting,  and  any 
irements  which  are  not  compatible  between 
the  CLA  (FDX  at  9600  bps)  is  expected  to 
between  the  SFEP  and  SCC.  The  final 
1 evaluation  unit  would  consist  of  a 
link  between  the  SCC  and  a remote 
ing  an  SCC  which  replaces  the  station 


Task  B3 
Interface 


Development 

Unit 


of  a SFEP/SCC  Functional  Evaluation 


Tne  purpose,  of  this  task  will  be  to  support  the  optimum  design 
study  (Task  B5)  through  evaluation  and  performance  testing  with 
hardware  mechanized  in  the  most  economic  methods  available.  T&E 
software  generated  for  tnis  task  shall  provide  the  basis  for 
future  software  development  in  an  optimized  prototype  unit. 

This  task  consists  of  developmental  efforts  in  the  areas  of 
hardware,  software  and  test  plans  for  initial  check-out 
activities.  The  hardware  portion  of  this  task  will  consist  of 
efforts  involved  in  obtaining  GFE  and  off-the-shelf  equipment, 
design  and  fabrication  of  custom  interface  elements  as  defined  in 
Ta  s k B 2 . 

The  software  portion  of  this  task  will  consist  of  test  and 
evaluation  type  software  to  be  used  by  the  SFEP  and  its  interface 
controller  module.  Initially,  the  SFEP  will  be  treated  as  a 
Secure  Communications  Processor  (SCOMP)  for  stand-alone  testing. 
Where  possible,  the  software  routines  generated  for  this 
configuration  shall  be  implemented  in  the  final  Multics 
prototype.  The  test  portion  of  the  software  shall  permit  testing 
and  verification  of  all  possible  functions  which  support  the 
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communications  interface  between  the  SCOMP  and  a remote  terminal. 
The  evaluation  software  will  be  developed  around  techniques 
determined  in  Task  B2  to  allow  measurement  of  performance  and 
otner  data  required  of  the  Functional  Evaluation  Unit. 

A test  plan  will  be  generated  to  describe  the  manner  in  which 
checkout  and  evaluation  tests  will  be  conducted  and  to  describe 
any  measurement  techniques  required  during  developmental  testing. 


Task  B4  SFEP/SCC  Functional  Evaluation  Unit  and  Multics 
Integration 

The  tested  Functional  Evaluation  Unit  from  Task  B3  will  be 
integrated  with  the  Multics  system  for  final  tests  to  support 
Task  B5-  To  achieve  this  integration,  a 60CC/Series  60  Interface 
Unit  is  required  to  provide  the  SFEP/Multics  interface. 
According  to  current  development  schedules,  this  task  could 
possibly  be  combined  with  integration  testing  of  the  6000/Series 
60  Interface  Unit.  Included  in  this  task  are  the  following 

subtasks : 

* Development  of  T&E  Multics  software  to  support  interface  witn 
tne  SFEP. 

* Development  of  T&E  SFEP  software  using  previously  generated 
subroutines  (Task  B3) . 

* Development  of  a test  plan  which  describes  the  test/evaluation 
data  required,  test  configuration,  and  measurement  techniques. 

The  output  from  this  task  will  be  a final  performance  and 
evaluation  report  which  will  contain  all  pertinent  information 
derived  from  Task  B3  and  tne  results  of  the  integration  tests. 


Task  B5  SFEP/SCC  Optimum  Interface  Design  Study 

The  purpose  of  this  task  is  to  optimize  a SFEP/SCC  interface 
design  which  eliminates  all  dual  or  redundant  functionalities  and 
interfaces  wnile  still  supporting  the  secured  multiline 

requirements  of  the  SCC.  To  be  considered  in  this  study  task 
will  be  possible  configurations  which  incorporate  tne  optimized 
functions  in  the  SFEP,  SCC,  or  a combination  of  both.  The  final 
configuration  will  be  the  result  of  trade-off  decisions  in  the 
areas  of  cost,  performance,  modularity  and  the  ability  to  meet 
requirements  previously  determined  in  Task  Bl. 

Major  items  to  be  considered,  but  not  limited  to,  in  the 
optimized  interface  design  study  are: 

* Security  aspects  and  validation 
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* TEMPEST  compatibility 

* Reduction  of  multiple  interconnecting  interface  types  (i.e., 
RS232  and  MIL-STD-188C  low-level) . 

* Reduction  of  redundant  multiplexing  functions  between  multiple 
communication  lines  of  the  SCC  and  the  GFEP  bus. 

* Overall  performance  requirements 

* Combined  line  controller  functions.  The  line  controller 

function  should  minimize  the  level  of  SFEP  software  support 
while  being  flexible  enough  to  accommodate  various  line 
protocols . 

The  output  from  this  task  will  be  a detail  specification  (Part  I) 
for  an  optimized  interface  unit,  preliminary  plans  for  T&E 
software  (for  stand-alone  and  integrated  tests),  and  definition 
of  possible  test  equipment. 


Task  B6  Development  of  an  Optimized  Prototype  Unit 

This  task  will  consist  of  developmental  efforts  for  an  optimized 

prototype  unit  in  the  areas  of  hardware,  software  and  testing 

directed  by  the  results  of  the  optimization  study  task.  This 

task  will  include  the  following  items: 

* Design  and  fabrication  of  one  prototype  unit. 

* Procurement  of  materials 

* T&E  software  developm.ent  for  stand-alone  tests  (i.e.,  without 
central  system) . 

* Test  equipment  development  for  stand-alone  tests  (including 
definition  of  GFE  and  off-the-shelf  equipment) . 

* Test  configuration/procedure  development  for  stand-alone 

tests . 

* Design  ver f ication/evaluation  tests  for  a stand-alone 

configuration . 

* Demonstration  tests  with  the  SCOHP/SCC  linked  to  a remote 
terminal  with  local  telephone  lines. 

* TEMPEST  qualification  tests  to  demonstrate  compliance  with  the 
TEMPEST  requirements  defined  in  Task  B5. 
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In  addition  to  the  hardware  and  software  generated,  a final 
detail  specification  (Part  II)  will  be  written  to  complete  the 
activities  of  this  task. 


Task  B7  Optimized  Prototype  Unit  Integration  with  Multics 

The  purpose  of  this  task  is  to  integrate  the  prototype  interface 
unit  with  the  SFEP,  SCO  and  the  Multics  host  central  system  to 
prove  the  SFEP/SCC  interface  design. 

To  achieve  this  integration,  a 6000/Series  60  interface  unit  and 
support  peripherals  will  be  required.  According  to  current 
schedules,  this  task  could  possibly  be  combined  with  the 
integration  testing  of  the  6000/Series  60  interface  unit. 
Included  in  this  task  are  tne  following  subtasks: 

* Development  of  T&£  Multics  software  to  support  the 

SFEP/Multics  interface. 

* Development  of  T&E  SEEP  software 

* Development  of  an  integration  test  plan  describing  the 

test/evaluation  data  required,  test  configuration,  and 
measurement  tecnniques. 

If  Task  B4  has  previously  been  implemented,  portions  of  the  above 
subtasks  will  already  have  been  developed. 


Task  B6  Final  Report 

The  objective  of  this  task  is  to  unite  all  data,  rationale  and 
trade-offs  obtained  from  all  the  previously  defined  tasks  into  a 
single  tecnnical  report. 
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MANPOWER  PI^JECT  GUARDIAN 

MANMOOTIIS/QUARTER  SFEP/CRYPTO  GRAPillC  MULTIPLEXER  INTEGRATION 

TASK  D 


Supporting  Effort  C:  Secure  Office  Terminal 


Task  Cl.O  INTRODUCTION  AND  OVERVIEW 

This  supporting  effort  encompasses  the  hardware  and  software 
activities  required  to  integrate  a Secure  Office  Terminal  into 
the  Secure  Front-End  Processor  (SFEP).  Integration  of  Secure 
Office  Terminals  into  the  (SFEP)  is  required  as  a part  of  the 
overall  effort  to  develop  a multilevel  Secure  Multics  for  DOD 
applications. 

The  hardware  integration  of  Secure  Office  Terminals  into  the  SFEP 
may  be  almost  totally  effected  via  existing  subsystems  and 
modules.  However,  this  may  not  be  the  most  cost-effective 
approach.  This  plan  encompasses  the  activities  required  to 
develop  a cost-effective  approach. 


A prime  approach  for  integration  of  Secure  Offi 
the  SFEP  is  to  utilize  the  Air  Force/ESD  Sec 
Controller  (SCC) . (1)  This  approach  utili 
Interface  Adapter  to  be  developed  under  Task  4. 
Guardian  Statement  of  Work.  (2) 


ce  Terminals  into 
ure  Communications 
zes  the  Custom 
8.3  of  the  Project 


The  software  modules  required  for  integration  of  Secure  Office 
Terminals  into  the  SFEP  will  be  developed  under  the  software 
development  activities  of  the  Guardian  Program.  This  includes 
the  software  required  for  the  lower  levels  of 
application-specific  interface  protocol  and  device  drivers.  The 
only  software  described  here  is  for  test  and  evaluation  purposes. 


The  planned  activities  for  accomplishing  the  integration  of 
Secure  Office  Terminals  into  the  SFEP  are  defined  in  Section 
C4.0.  The  attached  task  schedule  provides  an  estimate  of  the 
manpower  required  to  perform  these  tasks. 


Section  C2.0  TASK  PLAN 

Task  Cl  Integration  Requirements  Analysis 

This  task  will  define  the  end-to-end  hardware  and  software 
elements  required  to  integrate  Secure  Office  Terminals  into  tne 
SFEP. 


(1)  Secure  CdmmunicatTons  Controller  - Pro ject *78207oi/01. 

(2)  "Statement  of  Work  for  Secure  Multics  Design,  Development, 
and  Certification",  21  November  1975  (Revised).  Contract  No. 
F19628-74C-0193 
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Major  issues  which  will  guide  the  integration  requirements 
analysis  are  as  follows: 

1.  Communications  Security  (COHSEC) . 

Including  encryption  requirements;  multiplexed-encryption; 
single-xey/mul ti-key ; consumables  labeling  and  marking. 

2.  Concurrent  Multilevel  Operation. 

Including  multilevel  and  unilevel  terminals,  logical  security 
.enforcement;  line  handlers;  user  authentication;  and  device 
validation . 

3.  Functional  Modular  Partitioning. 

Hardware  and  software. 

4.  Error  Control. 

Including  initialization;  cyclic  redundancy  codes;  echoing 
and  parity. 

5.  TEMPEST. 

End-to-end  and  integration  requirements. 

6.  Secure  Data  Management. 

Including  pnysical  access  enforcement;  audit-trails; 
surveilance  and  external  alarming. 


TasK  C2  Integration  Configuration  Derivations 

This  task  will  trade-off  and  evaluate  various  end-to-end 
configurations  and  derive  a configuration  which  maximizes  use  of 
standard  nardware  and  software  functional  modules. 

Software  Partitioning 

The  major  part  of  the  Multics  and  SFE’p  software  will  be  developed 
under  major  Tasks  1 and  3 of  this  Integration  Plan.  This 
software  encompases  only  that  additional  software,  firmware,  and, 
perhaps,  hardware  which  is  required  for  integration  of  Secure 
Office  Terminals  into  the  SFEP. 

For  example,  due  to  the  advent  of  "smart"  terminals,  multiplexed 
cryptographic  devices  and  Multi  Line  Channel  Controllers,  whicn 
are  microcomputer-driven,  much  of  the  lower  levels  of  interface 
protocol  may  be  handled  by  these  devices.  These  should  be 
designed  to  be  transparent  to  the  higher  levels  of  protocol  with 
the  lower  level  devices  appearing  as  strictly  "logical"  devices. 
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t^ar ti tioni ng  r econiiTienaations  for  these  "lower-levels"  of  protocol 
will  oe  oevelopeu. 

iiaraware  Partitioning 

A generic  functional  partitioning  based  on  existing  subsystems 
snows  tnat  Secure  office  Terminals  may  be  integrated  with  the 
of£P  via  existing  stancara  subsystems  ana  mooules. 

An  alternate  particioning  baseo  on  the  ESD/DCvi  "Secure 

Communications  Controller"  (SCC)  eliminates  many  of  the  COhSEC 
aevices. 

Integration  Optimization 

The  rirst  nardware  subsystem  partitioning,  while  perhaps 
cosc-ef rective  through  its  use  of  standara  m.ocules,  indicates 
tnat  narcware  reounaancy  may  be  present  in  interface  modules, 
Tui-it-EST  filter,  cryptograpnic  and  channel  control  areas. 

Similarly,  tne  secona  partitioning  shows  that  nardware  redundancy 
(to  a lesser  uegree)  may  be  present  in  the  interface  module, 
TLi-irEST  filter,  time  division  multiplexor  and  channel  control 
areas . 

Tnis  suctask  will  trace-off  alternate  implem.entat ions  which  may 
reduce  the  narcware  ana  software  redundancies,  for  example,  the 
microprocessor  controlled  HLCC  induces  channel  multiplexing  and 
line  adapter  functions.  Furtner  integration  to  include  tne 
cryptograpnic  function  may  be  cost-effective. 

Selectee  Configuration 

Tne  selectee  configuration  will  oe  based  on  trace-offs  among  the 
following  tnree  prime  candidate  apprcacnes: 

1,  utilizing  cff-tne-shelr  encryption  devices  ana  multiplexors. 
X,  Utilizing  the  ESD  developed  SCC. 

3,  Utilization  of  custom  designea  mooules  which  proviae  a 
greater  degree  of  functional  integration, 

Tne  output  from  Task  C2  will  be  a Technical  Note  defining  the 
Integration  Configuration  aerived  including  block  aiagrams  and 
narewar e/software  functional  partitioning  requirements. 

Task  C3  functional  Evaluation 
Task  C3.1  Performance  Analysis 
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based  on 


Tnis  task  encompasses  a top-level  performance  analysis 
parametric  estimates  of  subsystem  performance. 

This  will  include  the  performance  impact  due  to  security 
constraints  such  as: 

1.  Cryptographic  and  keying  functions. 

2.  User  authentication  and  device  validation. 

3.  Secure  subsystems  performance. 

Task  C3.2  Test  Bed  System  Design 

Upon  completion  of  the  RNML,  SPM  and  6000/Series  60  lU 
integration  tests,  the  resultant  SFEP  may  be  utilized  for 
additional  evaluation  testing.  The  purpose  of  this  subtask  is  to 
procure  subsystem  modules  for  a test  bed  system.  This  test  bed 
will  be  configured  essentially  totally  from  off-the-shelf 

equipment  and  will  be  utilized  to  further  evaluate  end-to-end 
integration  of  secure  office  terminals  into  tne  SfEP. 

Tnis  will  include  multiplexed  cryptographic  subsystems  such  as 
the  ESD/DCW  "Secure  Communications  Controller"  or  standard 
multiplexors  and  KG ' s such  as  those  utilized  at  the  AFDSC 
installation.  Also  included  is  a secure  office  terminal  such  as 
tne  Secure  Teletype  .Model  40  or  the  Secure  Honeywell  hodel  7700 
VIP. 

The  test  bed  system  design  selection  will  be  based  on 
off-the-shelf  modules  which  replicate  the  functional  partitioning 
defined  under  Task  C2  of  this  task  plan. 

The  output  from  this  task  will  be  a tecnnical  note  which  defines 
the  test  bed  system  and  delineates  all  subsystems  which  must  be 
procured  or  provided  as  GFE. 

Task  C3.3  Test  and  Evaluation  Software  Design 

This  software  includes  basic  software  required  to  evaluate  the 
Secure  Test  Bed  system.  This  test  software  will  include  existing 
operating  system  and  application  software  modules  augmented  by 
protocol  and  device  driver  modules  peculiar  to  the  specific 
terminal,  and  COMSEC  devices  selected  for  the  test  bed.  Certain 
Kernel  and  operating  system  functions  may  require  simulation  at 
elementary  logical  leve'.s. 

TasK  C3.4  Integration  Evaluation 

The  Test  Bed  system  and  T&E  software  will  be  integrated  and 
utilized  to  demonstrate  end-to-end  Secure  Office  Terminal 
performance  and  throughput. 
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If  classified  COMSEC  equipment  is  utilized,  physical  security 
will  be  provided.  The  COMSEC  equipment  will  be  functionally 
utilized,  however,  operational  keying  will  not  be  employed  in 
order'  to  mitigate  or  eliminate  physical  security  requirements 
during  the  evaluation  tests. 

The  output  from  this  task  will  be  a technical  note  delineating 
performance  and  throughput  measures  and  physical  security 
requirements  for  -the  Secure  Office  Terminal. 


Task  C4  Final  Report 

A final  technical  report  which  describes  all  trade-off's 
performed,  all  design  selection  rationale  for  hardware  units,  and 
all  integration  data  will  be  provided. 
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Supporting  Eitort  u:  Security  Audit  and  Surveillance 

Section  Ll . u Ii'.ruOoUCTlGS  ASD  OVEkVILvv 

Inis  eirort  involves  extencing  the  capaoilities  oL  tne  secure 
i-iUitics  systeni  to  induce  a security  auoit  function  ana  a 
security  surveillance  function.  Both  of  tnese  functions  will  be 
unocr  tne  control  cf  tne  System  Security  Acministrator . 

<1  security  aucit  is  an  arter-tne-f act  exaniination  cf  system  logs 
ano  recorus.  Its  purpose  is  to  maintain  accountability  in 
accorcance  witn  tne  policy  of  the  DoC  Information  Security 
Brograai.  Tne  aucit  v/ill  cetect  unauthorizec  activities  within 
tne  system,  t.etect  attaci^s  of  the  system  (which  are  oefined  to 
rail  in  a certiriec  secure  system) , and  oversee  the  use  of  the 
system.  Events  ot  interest  to  a security  auoit  may  induce  the 
recoroing  ot  incorrect  passwords,  attemptec  unautncrizea  access 
to  segr.tents,  logins  by  selectee  persons,  logins  from  sdectcc 
terminals,  opening  ot  selectee  tiles,  and  all  oenials  of  access 
cue  to  laileo  security  cneciss  so  that  a security  aoininistr ator 
coulu  cetermine  past  events.  Since  tne  security  auoit  is 
ccncerneu  witn  recorcs  of  events,  it  presents  little  adoec 
exposure  for  tne  system  ana  may  ce  t ai r ly  easy  tc  cesign  anc 
ii..plem.ent . 

rt  security  surveillance  function  is  an  active,  cn-linc 
exam.ination  oi  activities  on  tne  system,  examination  cf 
interesting  events  as  they  occur  aiio  centinueo  mcnitcrinc  of  tne 
effectiveness  of  the  security  controls  (i.c.  subverter).  The 
purpose  of  security  surveillance  is  tc  micnitcr  for  unautnorized 
activities,  penetration  attempts,  etc.,  wnile  they  are  in 
process.  Security  surveillance  m.ay  induce  having  the  system, 
issue  alarms  when  selectee  persons  cr  selectee  terminals  Icgin , 
wnen  selectee  iiles  are  openee,  cr  when  selectee  security  checks 
are  raiieo.  Tne  function  may  also  involve  tne  .monitcring  of 
selectee  terminal  inter cnanges . An  active  process,  sometimes 
calicc  a “sueverter”  process,  may  be  usee  to  continuously  test 
tne  system's  security  m.echanism.s  ane  to  issue  an  alarm  if  any 
SGCcrxty  rr^  ec nanism  is  not  runctioning  properly.  Provision  of  the 
security  surveillance  function  may  result  in  special  case 
situations  ter  security  cnecks,  in  consieeraole  complication  of 
tne  kernel  m.echanisms , ana  in  tne  possioility  for  a substantial 
aaeeu  exposure  for  the  system.  As  a result  of  these 
consieerations , security  surveillance  m.ay  be  a difficult  function 
to  ocsign  ano  implem.ent . 

Bectior.  L2.U  T' Au h A LA.a 

lask  ol  otu^y  ano  Evaluation 

Tiiis  task  will  iirst  exteno  tne  stuoy  of  tne  security  audit  and 
surveillance  functions  Degun  ror  tne  AFDBC  ana  reported  in  a 
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tecnnical  report.  (1)  As  in  the  earlier  study,  this  must  be  a 
joint  effort  between  the  Air  Force  and  Honeywell,  with  each 
contributing  from  their  own  area  of  expertise.  In  particular, 
the  study  will  have  to  determine  the  extent  to  which  security 
audit  and  surveillance  is  required  in  a certified  secure  system. 
The  study  team  will  evaluate  the  costs  of  the  desired  features, 
considering  both  costs  in  system  performance  and  in  possible 
increased  exposure. 

The  requirements  for  the  security  audit  and  surveillance 
functions  will  be  specified  in  a technical  report.  This  report 
will  then  be  subjected  to  a comprehensive  design  review  to  ensure 
that  the  specified  functions  meet  the  security  requirements  of 
the  Air  Force. 

Task  D2  Functional  Specifications 

The  top  level  specifications  of  the  preceding  Task  D1  will  be 
sorted  into  kernel  and  non-kernel  items.  Those  items  that  must 
be  implemented  in  the  security  kernel  will  be  integrated  into  the 
specifications  developed  under  major  Task  1.  These  functions 
will  then  extend  and  join  the  Multics  kernel  development  task. 
These  features  must  be  subjected  to  the  full  discipline  of  the 
Multics  kernel  development.  They  should  be  targeted  for 
inclusion  with  Multics  Prototype  Number  3.  This  requires  that 
the  program  be  started  essentially  at  the  start  of  major  task  1. 
Non-kernel  items  will  be  described  by  a functional  specification 
wnich  will  be  issued  as  a technical  report. 

Task  D3  Implementation 

The  items  within  the  kernel  will  be  implemented  by  an  extension 
of  major  Task  1.  The  non-kernel  items  will  be  implemented  under 
this  task.  A preliminary  manual  for  the  System  Security 
Administrator  will  be  prepared  to  assist  in  the  use  of  the  audit 
and  surveillance  functions. 

The  security  audit  and  surveillance  functions  will  be 
demonstrated  in  conjunction  with  Multics  prototype  Number  3. 


(1)  J.  Whitmore,  et  ai,  "Design  for  Multics  Security 
Enhancements",  ESD-TR-74-176 , Honeywell  Information  Systems, 
Inc.,  Cambridge,  MA,  December  1973. 
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Appendix  B 

Air  Force  BSD  Comments 


Page  28  --  Line  +2  (second  line  from  top  of  page) . Definitive 
goals  as  well  as  products  need  to  be  defined  for  the  program 
correctness  proofs  task. 

Page  28,  Task  1.28  — This  task  avoids  discussion  of  a potential 
interface  with  the  Autodin  II  message  switching  network.  The 
design  for  a network  should  be  modular  so  as  to  be  adaptable  to 
Autodin  II. 

Page  29,  Task  1.29  — Tnis  task  does  not  appear  to  be  a tecnnical 
task  but  ratner  a management  task.  Honeywell  should  try  to 
utilize  existing  trained  and  cleared  personnel  whenever  possible. 

Page  31-34,  Tasks  1.33-1.40  — Although  these  tasks  address  the 
analysis  of  security  vulnerability  due  to  hardware  failure,  there 
is  no  mention  of  developing  techniques,  procedures  or  software 
for  minimizing  the  occurence  of  the  failures  found  to  seriously 
affect  tne  operating  of  tne  certifiable  Multics  system . 

Page  33,  Task  1.37  — The  objective  of  this  task  is  not  clear. 


